Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes What if the same client execute lockRecord twice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "What if the same client execute lockRecord twice" Watch "What if the same client execute lockRecord twice" New topic
Author

What if the same client execute lockRecord twice

Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Hi Everybody,

I am doing the URLyBird Version 1.2.1 currently. I would like you to advise me on the lockRecord() method.

It is stated that "If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked". The question is what is supposed to happen if a client execute the method twice? With the code I wrote, the thread waits forever in the loop.

These are my method. Anybody would like to give me a suggestion?

Pushkar Choudhary
Rancher

Joined: May 21, 2006
Posts: 425

Just Nothing wrote:

Please change your display name to use your real first and last names. Obviously fictitious names are not allowed under JavaRanch's Naming Policy.
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Pushkar Choudhary wrote:
Just Nothing wrote:

Please change your display name to use your real first and last names. Obviously fictitious names are not allowed under JavaRanch's Naming Policy.


Ok, I just changed it. It is weird though.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

Hi Jack,

I throw an IllegalSateException. But there are other alternatives. Useful information can be found in this thread.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2247

Roel De Nijs wrote:I throw an IllegalSateException.


Me too!


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Thanks for the advices. I think I get it.

But how you do you keep tracking what client locking what recNo? Since the interface doesn't include clientId, I guess it must be done at the upper layer.

Am I right?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

Hi Jack,

If you are able to follow the same approach depends on which interface you have. If you have an interface with the infamous lockCookie you'll not able to track down which client locked which record. If you have one without the lockCookie (like me and Roberto) you can add a client-dentification method to your own interface (which extends the given - required to implement - interface). This approach is described in this thread (and in a bunch of other threads too ).

Kind regards,
Roel
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Roel De Nijs wrote:Hi Jack,

If you are able to follow the same approach depends on which interface you have. If you have an interface with the infamous lockCookie you'll not able to track down which client locked which record. If you have one without the lockCookie (like me and Roberto) you can add a client-dentification method to your own interface (which extends the given - required to implement - interface). This approach is described in this thread (and in a bunch of other threads too ).

Kind regards,
Roel


I got the one with the cookie. So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row? this cause the thread waits forever.

I am thinking to create an upper layer to manage the security exception related to the cookie. Anybody have any experience or opinion about this would be appreciated.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2247

Howdy, Jack!

So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row?


Oh, you certainly can track the client. After some thinking, I realized that maybe, what they expect from us is to realize that, if your lock() method does not return a value, then you should implement a thin client. This way, the transaction will be controlled on the server side. If it returns a value, then you can either implement a thick or a thin client.

This is my answer to my good buddy Andrew's question: Should lock methods be callable by the client? Well, if the lock() method return a value, then you may control the transaction on the client side, and expose the lock() method in a remote interface to the client. On one hand, it is easy due to the value returned; on the other hand, it's like using the Exposed Domain Model pattern. Particularly, I don't really like the idea of controlling the transaction on the client side. If your lock() method does not return a value, then it is easy to control the transaction on the server side using Thread.currentThread().getId(), and then you'll not expose the lock() method to the client.

In the case of the thin client, your business method is implemented on the server. Consider the following (just notice the modeling so you can understand):



If your lock() method returns a value, you can then return it to the client side and implement the locking logic there. I myself came up with a different approach (you can find more info about it here), and I agree that it introduced a little more complexity than necessary. My lock() method does not return any value, but I came up with a way to implement a thick client, and controlling the transaction on the client side.
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Roberto Perillo wrote:Howdy, Jack!

So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row?


Oh, you certainly can track the client. After some thinking, I realized that maybe, what they expect from us is to realize that, if your lock() method does not return a value, then you should implement a thin client. This way, the transaction will be controlled on the server side. If it returns a value, then you can either implement a thick or a thin client.

This is my answer to my good buddy Andrew's question: Should lock methods be callable by the client? Well, if the lock() method return a value, then you may control the transaction on the client side, and expose the lock() method in a remote interface to the client. On one hand, it is easy due to the value returned; on the other hand, it's like using the Exposed Domain Model pattern. Particularly, I don't really like the idea of controlling the transaction on the client side. If your lock() method does not return a value, then it is easy to control the transaction on the server side using Thread.currentThread().getId(), and then you'll not expose the lock() method to the client.

In the case of the thin client, your business method is implemented on the server. Consider the following (just notice the modeling so you can understand):



If your lock() method returns a value, you can then return it to the client side and implement the locking logic there. I myself came up with a different approach (you can find more info about it here), and I agree that it introduced a little more complexity than necessary. My lock() method does not return any value, but I came up with a way to implement a thick client, and controlling the transaction on the client side.


Roberto, thanks for the input.

I think thin client approach offers simplicity, but on the minus it doesn't allow client to do the pessimistic transaction (might be not necessary).


Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4925
    
  10

Jack,

Please, don't quote a complete post of someone else. It has no added value and just wastes some disk space. Use quotes wisely!

on topic: if you have a lockCookie you can't know if clientA has already locked another record (in your Data class). You can add of course this logic on a higher level or you can just do something like this:
However, this can easily be remedied by ensuring the JavaDoc and the choices.txt clearly define that it is the responsibility of the client to ensure lock/update/unlock is one atomic operation, ie. that the unlock is called on a locked record prior to locking the same record again:
More info found in this post.

Kind regards,
Roel
 
Consider Paul's rocket mass heater.
 
subject: What if the same client execute lockRecord twice
 
Similar Threads
Potential deadlock scenario
No definition of what is a DuplicateKeyException
URLyBird: how to calculate clientId
Appealing grading results?
Cookie value used in DBAccess Interface