Just Nothing wrote:
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.
Roel De Nijs wrote:I throw an IllegalSateException.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
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
So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
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.
More info found in this post.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:
Whatever. Here's a tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
|