(B&S):Lock cookie importance

[Saheed Adepoju]

Hi all
I was pondering hard about something!The lock cookie which i must generate for my assignment, how important is it really! I am going to implement it, but I would like a good scenario so as to better understand its importance! I know it is used to lock the particular record(Client that locked the record)! Of what great importance is it as compared to the solution provided by Max in his book!Thanks!

[s yucel]

hi,
i had the same problem, and I am thinking to use the thread id as it is a unique value.

kind regards,

[Andrew Monkhouse]

Hi Saheed,

Consider the following scenario:

Client A reads record 1
Client B reads record 1
Client A confirms record 1 is available for updating
Client B confirms record 1 is available for updating
Client A updates record 1
Client B updates record 1

So now both client A and client B think that they have booked record 1

This can be mitigated with record locking:

Client A locks record 1
Client A reads record 1
Client B attempts to lock record 1 - blocks until available
Client A confirms record 1 is available for updating
Client A updates record 1
Client A unlocks record 1
Client B locks record 1
Client B reads record 1
Client B confirms record 1 is no longer available for updating
Client B unlocks record 1

However this relies on the two clients playing nicely, and agreeing to lock records. Consider if one client does not play nicely:

Client A locks record 1
Client A reads record 1
Client B reads record 1 (without attempting to lock  :shock:  )
Client A confirms record 1 is available for updating
Client B confirms record 1 is available for updating
Client A updates record 1
Client A unlocks record 1
Client B updates record 1

So once again we have the problem that two clients have booked the same record, even though one did follow the rules.

The typical response at this time is that "this cannot happen in my solution, as I have chosen not to allow network clients access to the Data class' update() method. Quite apart from the fact that I personally don't believe that this is meeting the stated requirements (although I acknowledge that people can still pass doing this), the big problem is that it relies on a particular server implementation - if the client decides to rewrite the implementation of the server and just reuse your Data class then the problem could suddenly start manifesting itself.

However if you use cookies, then the client calling the update() method must know the correct cookie to use, otherwise the call to update() will fail. So that last scenario cannot occur.

Regards, Andrew

[Andrew Monkhouse]

Hi

Originally posted by s yucel:
hi,
i had the same problem, and I am thinking to use the thread id as it is a unique value.

Just be aware that if you are using RMI and exposing your Data class' methods via the remote interface that the thread ID could change between calls. It may not matter for your usage, however it can mean that two separate clients could get the same cookie (thread ID).

Regards, Andrew

[Christopher Bareja]

Hi,

Andrew, I did understand,that in your solution client is loking every record whil reading it (for showing in table) and releasing it while closing/reloading table/ etc? Am right?

Some people on this forum have different idea: To do "lock-update-unlock" block after the "Update" button. I don't like this solution - it is possible to overwrite someones reservation without even knowing it.

In my version I've decided to have functionality of displaying table without locking. When user presses "Reserve" button client is
-locking,
-reading row
-displaying locked row in separate dialog
-waiting for user input
-after confirmation updating an unlocking
The only problem what i see is that record can be in "lock" state for quite a long time. I want to preserve it by adding listener pattern for broadcasting information about locking and other changes. Locked records wouldn't be able to select.But it breakes the simplicity rule a bit. What do you think?

Regards
Chris

[Alex Sharkoff]

Andrew Monkhouse wrote:

  Client A locks record 1
  Client A reads record 1
  Client B reads record 1 (without attempting to lock  [shocked]  )
  Client A confirms record 1 is available for updating
  Client B confirms record 1 is available for updating
  Client A updates record 1
  Client A unlocks record 1
  Client B updates record 1

....
So once again we have the problem that two clients have booked the same record, even though one did follow the rules.
....
However if you use cookies, then the client calling the update() method must know the correct cookie to use, otherwise the call to update() will fail. So that last scenario cannot occur.
<hr></blockquote>

It seems that even with the use of cookies we can have two clients booking the same record:

Client A locks record 1
Client A reads record 1
 
Client B reads record 1 (without attempting to lock  [shocked]  )
 
Client A confirms record 1 is available for updating
Client B confirms record 1 is available for updating
 
Client A updates record 1
Client A unlocks record 1
 
Client B locks record 1  [B](locking before updating)[/B]
Client B updates record 1 [B](will not fail because client B locked it)[/B]
Client B unlocks record 1

I think it all comes down to the client complying with the contract provided by the DBMain interface (the interface that is implemented by the Data class). What we say in this contract is that when the client needs to modify the record via the implementations of DBMain interface it must execute the following steps in the specified order:

1) lock the record via DBMain#lock

2) modify via DBMain#delete or DBMain#update

3) unlock the record via DBMain#lock

The DBMain conract does not say anything about business logic that might occur between steps 1 and 2 (eg, read the record in order to determine if it can be updated) because it is up to the client to decide. However, what DBMain implementations might do in update and delete methods is to verify whether the client who is calling the method has locked it. If not the update fails.

Of course, there is nothing that stops the client breaking this contract (as shown in the examples above). But what happens to the one who breaks the contract? He is punished


Andrew wrote

if the client decides to rewrite the implementation of the server and just reuse your Data class then the problem could suddenly start manifesting itself.

I think by providing us with DBMain interface and Data class SUN gives us a hint: use Data Access Object pattern. What don't we have in order for this pattern to be complete? Yes, a Business object and a Transfer object. Well, our Business Object will be DBClient (which will have remote and local interface; it is not a client GUI) and Transfer object will be a ContractorTO. If there is requirement to plugin a new data source (eg, MySQL) then we create a new class that implements DBMain.
If the client decides to rewrite the implementation of the server (i believe you meant the network server) it will leave Data Access components untouched. Plus there is always a contract that comes with the use of DBMain implementations


Thanks a lot for reading my little novel,

[ December 20, 2005: Message edited by: Alex Sharkoff ]

[Andrew Monkhouse]

Hi Christopher,

Andrew, I did understand,that in your solution client is loking every record whil reading it (for showing in table) and releasing it while closing/reloading table/ etc? Am right?

No - I was only showing the "booking" business logic which (in my example) has a call to lock and a call to read in it. But clients calling read() or find() would not need to lock records.

In my version I've decided to have functionality of displaying table without locking. When user presses "Reserve" button client is
-locking,
-reading row
-displaying locked row in separate dialog
-waiting for user input
-after confirmation updating an unlocking
The only problem what i see is that record can be in "lock" state for quite a long time.

Ahh - the question about optimistic or pesimistic locking. Searching for either of those terms in this forum will bring up a few posts on the subject. Suffice it to say that both ways are valid, although the optimistic locking solution tends to get greater supporters here. Mainly because of the potential for a client to click the "Reserve" button (thereby locking the record) then receiving a phone call / being called away ... Another client tries to reserve the same record and effectively gets blocked (it may appear that the client application has frozen) until the first client gets back to whatever they were doing.

I want to preserve it by adding listener pattern for broadcasting information about locking and other changes. Locked records wouldn't be able to select.But it breakes the simplicity rule a bit. What do you think?

Nice workaround to the problem I just mentioned (which is why I mentioned it above and not here ). However you are going to build a much larger solution than is really needed - you might want to consider how much less effort is going to be required with optimistic locking.

Regards, Andrew

[Andrew Monkhouse]

Hi Alex,

It seems that even with the use of cookies we can have two clients booking the same record[...]

Doh!

Yep - even with cookies, someone can write bad business logic and break the system.

Thanks for your little novel

Regards, Andrew

[Alex Sharkoff]

Andrew wrote:

Thanks for your little novel

No worries, mate

How does everyone find the novel's content (client must comply with the contract; Data class only checks whether the record is locked when modifying this record via update or delete; Data Access Object pattern)?

All objections and comments are welcome.