aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes (B&S):Lock cookie importance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "(B&S):Lock cookie importance" Watch "(B&S):Lock cookie importance" New topic
Author

(B&S):Lock cookie importance

Saheed Adepoju
Ranch Hand

Joined: Jun 23, 2004
Posts: 267
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!


Saheed Adepoju<br />SCJP 1.4<br />SCJD (B&S..In progress)
s yucel
Greenhorn

Joined: Dec 04, 2005
Posts: 11
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11479
    
  94

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11479
    
  94

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
Greenhorn

Joined: Nov 13, 2005
Posts: 6
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
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
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 ]

    Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11479
        
      94

    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
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11479
        
      94

    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

    Joined: Apr 11, 2004
    Posts: 209
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: (B&S):Lock cookie importance