• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

locking without cookies

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 Data.java 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?
 
author and jackaroo
Posts: 12199
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jason Hocker
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Why fit in when you were born to stand out? - Seuss. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic