Should the client be responsible for locking?

[Arjan Broer]

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]

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]

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]

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]

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 ]