I'm getting close to finishing my assignment (URLy bird 1.1.2) and have now reached the paranoia stage
I'm reasonably happy with my design and it appears to work correctly. However 3 things that I see on this forum cause me to question my design:
1) Client IDs for the server to identify specific clients 2) Connection factory with dedicated remote object for each client 3) Why does nobody use the lockable object pattern ?
I see the need for neither 1 nor 2.
1)In the DB interface I was given, the method signatures are: public void update(int recNo, String data, long lockCookie) public void delete(int recNo, long lockCookie) public long lock(int recNo) public void unlock(int recNo, long cookie)
...Surely the lock cookie identfies the client who locked the record - why do we need extra checks ? I'm assuming we don't have crackers trying to spoof the lock codes to get free rooms.
2) Multiple remote objects - isn't this just wasting server memory ? I imlemented a 3-tier design with a single remote Facade object wrapping a singleton Data class. The Facade object has no state (no member variables) so there is no real benefit to having multiple instances. RMI gives us multi-threading for free. Although consecutive client calls won't necessarily occur in the same thread, in the Facade pattern there is only ever a single call to a business method. This will run on the server-side and should accomplish all low-level Data access calls in one thread. (Correct me if I'm wrong)
3) Everybody seems to have a LockManager. In fact I did too until last week when I read about this alternative which is both more intuitive and simpler to code. I synchronize my business methods on the Record object. I use the lockable-object pattern - a Record knows itself whether it's locked or not and has the lock cookie to know who is the owner. If it's locked you just wait on the Record until it's available. So why when I search the forum for 'lockable object' do I see no matches ?
I'm sure there are errors here but it looks right to me - I just need a little reassurance. Let me know me your thoughts.
Andrew [ September 12, 2005: Message edited by: Andrew Rowland ]
Some of your questions might be answered in the JavaRanch SCJD FAQ, specifically in the answer to "How may assignments are there?" Take a look at all the different signatures for the unlock method.
Surely the lock cookie identfies the client who locked the record - why do we need extra checks ?
Agreed - as long as you have a lock cookie. Many candidates are not allowed to have a lock cookie, in which case some other method of identifying the client is required. A connection factory is one simple method of handling this.
Multiple remote objects - isn't this just wasting server memory ?
Possibly (for your solution). However it can be an elegant solution to the problem of identifying clients if you are not allowed lock cookies. And it can provide better performance for those with lock cookies if you set up a pool of connections (and a pool manager).
So why when I search the forum for 'lockable object' do I see no matches ?
Similar concepts are discussed from time to time, however the end result is usually that the Data class must provide the lock methods, and the Data class does not provide a lockable object - it provides things like int and String.
Thanks for your comments Andrew - quick off the mark as ususal
The first 2 points I concede are project-dependent. I didn't realise the diversity of the locking method signatures depite looking at the FAQ some time ago - my apologies.
On the Lockable Object concept, I still think there's some mileage in there. My Data class has a cache of records held by a RecordManager. I have kept all implementation details out of the Data class iteslf by using an interface...
So the Data class calls and lock/unlock methods just end up delegating to record.lock()/record.unlock() which are themselves synchronized. The amount (and distribution) of code is much simpler and more pleasing to the eye than my previous LockManager imlplemtation.
Similar concepts are discussed from time to time
I'm having no luck searching for threads on this issue - if you have links to any I'd be very grateful
Still open to criticism on this technique.
author and jackaroo
Sorry, I don't have a lot of time to search for posts today or tomorrow. If you search for consumes no cpu cycles in this forum you will find (a lot of) posts saying that you don't need to be precise about this requirement, plus a few posts talking about similar concepts to yours (with minor variations). Take a look at Lara McCarver's posts in "Elegant solution to waiting without CPU activity?" - you should be able to see the similarity (as well as a few differences).