Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lockable objects and client IDs

 
Andrew Rowland
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thanks

Andrew
[ September 12, 2005: Message edited by: Andrew Rowland ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11907
207
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,

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[].

Regards, Andrew
 
Andrew Rowland
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thanks

Andrew
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11907
207
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,

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).

Hey Lara - are you reading this? Any comments?

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic