File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes A question about Instructions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "A question about Instructions" Watch "A question about Instructions" New topic
Author

A question about Instructions

Chris Chang
Greenhorn

Joined: Sep 02, 2002
Posts: 14
In my instruction file, there is a statement as following

My question is if the lock/unlock method should be provided in remote client ? It seems no meaning to do this. It should control under RMI server instead of client.
Tks !
[ August 09, 2003: Message edited by: Chris Chang ]
Mike Southgate
Ranch Hand

Joined: Jul 18, 2003
Posts: 183
It seems to me that the tracking of the locks HAS to be done on the server side. The client only asks for a lock an keeps track of any lock(s) it holds. The server side tracks all locks held by all clients. So, assuming your Data class is on the server side then their instructions are consistent with what you need to do.
ms


ms<br />SCJP, SCJD
Jason Dobies
Greenhorn

Joined: Aug 13, 2003
Posts: 20
This was the only rule in the instruction file that I blatently violated. I couldn't bring myself to expose the inner workings of the database across the wire, so I hid most of database method calls server-side and exposed business logic through RMI. I wasn't penalized for doing so, I just made sure to explain my choice in the design document.


JCP, JCD, WCD... and all around nice guy.
Svetlana Koshkina
Ranch Hand

Joined: Jul 08, 2003
Posts: 108
Originally posted by Jason Dobies:
This was the only rule in the instruction file that I blatently violated. I couldn't bring myself to expose the inner workings of the database across the wire, so I hid most of database method calls server-side and exposed business logic through RMI. I wasn't penalized for doing so, I just made sure to explain my choice in the design document.

You are very brave. I made my client (the layer between gui and the server) to implement all methods that they asked, but i did not used them because...you all know why. One reason i did that, i thought they might use harness to test our programs so they needed interface but it looks now like they don't.
I am anxiously waiting for my results, why i dont post too much here and don't want to pester people with my ideas which might prove not so good.
:roll:
Eugene Sun
Greenhorn

Joined: Aug 09, 2003
Posts: 17
Hi guys,
I disagree with you on this requirement. I am working on FBN project also.
I think requirement
The remote client code that you write must provide all the public methods of the suncertify.db.Data class.

makes total sense. Hear me out.
First of all, Let me ask you guys a question. When you implement the local mode, do you call lock and unlock method on the Data class in your GUI?
I do in the local mode.
For the networked mode, RMI is supposed to serve as the proxy for the server to allow GUI to call (Data Client is the proxy here) , so the calls made on the Data Client should be exactly like the ones made in the local mode on the Data Class directly, only they are really remote.
Correct me if I am wrong.
Thanks,
Eugene
That's why I don't see anything
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11279
    
  59

Hi everyone
[Jason] This was the only rule in the instruction file that I blatently violated.
[Svetlana] You are very brave.

Wow, I agree with Svetlana. I read the word "must" and didnt dare to deviate.
[Eugene] When you implement the local mode, do you call lock and unlock method on the Data class in your GUI?
I do in the local mode.

I know there people who have passed who used lock() and unlock() on the client side in networked mode who did not use lock() and unlock() in local mode. There are also people who did have lock() and unlock() methods in local mode, but didnt have them call Data's lock() and unlock() methods - they were just dummy methods.
Personally I did do the complete lock() and unlock() in local mode, just because I hate having code which does different things in local versus networked mode.
I also agree with having lock() and unlock() methods client side. If you are calling the other Data methods such as modify() remotely then you need to be able to lock the records remotely. The only other alternative is to stop clients calling the modify() method remotely, and force them to use business type methods (for example a remote bookFlight() method). Having the standard lock() and modify() methods available to the clients is more extensible in the future, as client software can be modified for some functionality changes, without affecting other running clients or the server. If you use business methods then many functionality changes are likely to affect the server, which is going to affect all running clients.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Jason Dobies
Greenhorn

Joined: Aug 13, 2003
Posts: 20
First of all, Let me ask you guys a question. When you implement the local mode, do you call lock and unlock method on the Data class in your GUI?
I do in the local mode.

Even in local mode I don't directly make these calls from the GUI. To me, that is logic that shouldn't exist in a GUI, local or remote. I ran the local GUI on the same business logic classes the remote GUI used. Whether or not the DB was local or remote was transparent even at the business logic level.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: A question about Instructions
 
Similar Threads
Running a RMI Application
Need to extend UnicastRemoteObject class
Eclipse lomboz deployment to Linux via samba
How to understand Passed by Reference or Copy of Value for Local or Remote Interface?
About packaging