It's not a secret anymore!
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes locking without cookies 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 "locking without cookies" Watch "locking without cookies" New topic

locking without cookies

Jason Hocker
Ranch Hand

Joined: Jul 23, 2003
Posts: 132
I am sure this has been discussed many times, but when I read over the old posts, I get confused by the different assignments. Some assignments use cookies in the interface, and some do not.

I have the non-cookies approach. I'm confused... how will I know if this client has locked this record?
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778

Hi Jay,

What you need is something that is unique per connected client - and the most "obvious" choice (thread number) can't be used, as there is no guarantee that a single client will use the same thread twice, or that another client won't use the same thread.

One simple way of handling this is to create an instance of the Data class for each connected client. You can then use the instance of the Data class to identify the owner of the lock. You could do this by setting up a connection factory on the server - instead of doing an RMI lookup which returns the one instance of the remote object, you do an RMI lookup which returns a factory which has a method you can call to get a unique instance of the remote object. This unique instance can have it's own instance of the Data class, and so on.

You might then want to think about whether you have a static lock collection, or whether you have a common lock manager class. Likewise you might want to think about whether you have the Data class accessing the database file directly, or whether it calls helper classes to access the database file (so your Data class could become a Fa´┐Żade).

Another advantage of having the Connection Factory is that it makes it simple to handle client's dying later (if you want to do this) - since you have a unique remote object per client, you can use the Unreferenced interface or some collection that uses WeakReferences (e.g. WeakHashMap) to store your locks.

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 Hocker
Ranch Hand

Joined: Jul 23, 2003
Posts: 132
Thank you very much. My original plan was to have one instance of Data, and use thread name as the key to a hashtable. I will rethink my design.
I agree. Here's the link:
subject: locking without cookies
It's not a secret anymore!