File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Should the client be responsible for locking? 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 "Should the client be responsible for locking?" Watch "Should the client be responsible for locking?" New topic
Author

Should the client be responsible for locking?

Arjan Broer
Greenhorn

Joined: Dec 20, 2002
Posts: 20
Hi all,
When i analyse the locking model of other database systems i must conclude that the server is responsable for aquiring locks on records on behalf of the client. With a SQL update statement the client implicitly requests a record lock, but the server is responsable to handle the lock-update-unlock sequence.
This sounds fair when you take into consideration that a client programmer makes a stupid mistake by implementing the sequence update-lock-unlock.
My question here is if we should expose lock and unlock to the client and if we should implement an implicite lock.
(excuse me for my spelling)
Regards
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Arjan Broer:
My question here is if we should expose lock and unlock to the client
You are required to have a client-side class implementing all the public methods in Data. That makes the answer to your question an undoubted "yes".
and if we should implement an implicite lock.
This is not a requirement, and it would not be sufficient to prevent race conditions between two clients booking a seat on the same flight. (Unless you implement a server-side book() method, which would make total nonsense of the requirement to have a client-side Data-like object and reduce reusability to zero: not a good idea).
Having said that, I coded my server to acquire implicit locks for clients trying to write() or delete() a record they had not obtained a lock for, and release these locks afterwards. Given that the server classes were to be coded for reuse (is that still in the reqs?) I figured I couldn't count on other developers to be totally disciplined acquiring locks. You can easily argue that this is out of scope for the project, but at least I didn't lose any points over it.
- Peter
[ January 16, 2003: Message edited by: Peter den Haan ]
Arjan Broer
Greenhorn

Joined: Dec 20, 2002
Posts: 20
Originally posted by Peter den Haan:
I figured I couldn't count on other developers to be totally disciplined acquiring locks.

I fully agree that other developers can not be trusted to use your server as you itended. But does that mean your server has to do the work they forgot to implement, or should you throw an exception for misusing your server.
When the stupid programmer, i mentioned above, implements update-lock-unlock. He could think this is correct due to the implicit lock.
If you implement an implicite lock, shouldn't we also check if the client had the most up to date record?
I personaly don't think so, because of the scope of this assignment. This would mean that an exception should be thrown when misusing the locking model.
Did i just make a design decision???
please critisize.
[ January 16, 2003: Message edited by: Arjan Broer ]
Bernhard Woditschka
Ranch Hand

Joined: Sep 16, 2002
Posts: 89
You do - that's fun isn't it
In comercial databases the users may choose to unlock manually : 'commit' and 'rollback'
Bern
[ January 16, 2003: Message edited by: Bernhard Woditschka ]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Arjan Broer:
[...] But does that mean your server has to do the work they forgot to implement, or should you throw an exception for misusing your server.
That was the other plausible choice. Yes, that'd be fine as well. I chose the implicit lock way because that's how an RDBMS would behave. It's simply the behaviour I happen to be comfortable with... of course, in my design decision document, I argued that it had to be this way because other developers would be likely to be more comfortable with this behaviour
If you implement an implicite lock, shouldn't we also check if the client had the most up to date record?
You can't, of course. But my primary aim was not to protect a stupid programmer against him/herself, but to protect all the nice programmers holding locks against a stupid one trying to clobber their locked record.
Did i just make a design decision???
Don't worry. We will all pretend we didn't notice
- Peter
[ January 16, 2003: Message edited by: Peter den Haan ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Should the client be responsible for locking?