• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

lock & unlock

 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello.
I've been thinking about the lock and unlock methods for the assignment and after reading some of the posts here I make one question. What's the point in have the clientID in the lock?
If everything is done the correct way, read->lock->write->unlock, only the client that as get the lock on the record will try to unlock it as the other clients that try to lock the same record will be put in a waiting state until the record get's unlocked!
Please comment.
Thanks,
Miguel Roque
 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Miguel
also for a given client, if this one makes a request and locks a record, nothing can prevent that a second request from the same client on the same record put that request in wait state instead of being ignored.
what you are discussing here is to design or not the lock subsystem in an unsuspecting way, taking some assumptions on how it will be used.
althought you now that in the way you are implementing the application these situations will not be allowed, i think the lock subsystem should be designed with independence of its context ( the rest of the application), and not trust in the good behaviour of other components that have no relations with it. you will have there a dangerous functional coupling.
[ December 18, 2002: Message edited by: Jaun Katabasis ]
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jaun.
You mention that the same client can ask for the lock of the same record. Well, this will cause the same client to be put in a waiting state as the record is locked!
Also, the idea is that when a client books a seat, a new window will popup with a message like "Processing your request. Please wait.". This way, the same client can't try to lock the same record or other record.
Thanks,
Miguel
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Miguel Roque:
[...] What's the point in have the clientID in the lock? If everything is done the correct way, read->lock->write->unlock [...]

Stop right there. You are making a mistake. You are thinking of the database as something purely for the Fly By Night project. In fact, your instructions tell you that is not the case. Heck, the code itself tells you that is not the case; Data is a perfectly generic piece of code.
First and foremost that means that it is a mistake to talk about "the correct way". The applications written against the database will have all kinds of correct ways. I've written plenty of code against SQL databases where I do not know if I've already locked a given record in the transaction or not, and where I certainly do not want to care.
Second, Data is intended for re-use. Reuse by others, potentially. This means you have to pay much more attention to "bomb-proofing" the API.
And finally, in case you had any doubts Sun gives a not-so-gentle hint in the javadoc for the unlock() method.
- Peter
[ December 18, 2002: Message edited by: Peter den Haan ]
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello.
After reading many of the post's here, I will go to the most used solution that is to include the userID (you are right Peter, in the javadoc there is the answer).
Now, should I implement the LockManager class as a Singleton? I think that this is the best solution!
Thanks,
Miguel
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, Singleton. Poor, overused, abused, bruised and battered Mr Singleton. They hire him for all kinds of things, even if he can't really do much good at all. And sometime later everyone's upset with him about the work he's done, even though he just did the job he was asked to do. You must feel sorry for Mr Singleton.
Not a good idea (you saw that coming, right?)
Of all the GoF patterns, Singleton is the most abused. Singletons are appropriate when there is a fundamental reason why you can and should have only one instance of a given class. The fact that you happen to need only one in a particular case isn't good enough. There must be a reason that is fundamental to your design.
There isn't. Worse, a Singleton is harmful.
Reusability is once again a keyword here. How many database-driven applications do you know that can make do with just one database table? With local databases, nothing prevents you from using as many Data instances as you like, each representing a table. If LockManager were a Singleton, you would be restricted to just a single remote Data instance per server, reducing reusability to, erm, well, just about zero.
A one-per-Data "Singleton" would be fine, but a real, one-per-JVM Singleton is surely a mistake.
- Peter
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic