• 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

(B&S):Lock cookie importance

 
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,
i had the same problem, and I am thinking to use the thread id as it is a unique value.

kind regards,
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Saheed,

Consider the following scenario:So now both client A and client B think that they have booked record 1

This can be mitigated with record locking:However this relies on the two clients playing nicely, and agreeing to lock records. Consider if one client does not play nicely: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
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew Monkhouse wrote:

....
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:


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
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 209
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic