Originally posted by Michal Charemza:
However, this behavior is only guaranteed because of the way I implement the calling class. Some possible future class could call lock() on behalf of one client, and then call "update()" on behalf of another, but all in the same thread (this could happen with multiple RMI calls), and so the second would illegally be able to update the record.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Reza Rahman:
Just out of curiousity, you will still be doing the Thread.currentThread().setName()/getName() trick to check that the exact client that requested lock is doing the unlock, right? Remember, the opposite situation, that is, more than one client using the same RMI thread is very common in your scenario. Just making sure.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Reza Rahman:
As far as I know, in the scope of this project, ReentrantLock won't get you anything more than what you are already getting with the synchronized keyword (feel free to tell me I am wrong, I haven't really used java.util.concurrent on a real project and my knowledge is shallow in that area).
Originally posted by Reza Rahman:
2. It will also act as a final fail-safe for you code. Please don't ask how your code might break -- let me pose a hypothetical:
Suppose that there is a bug in your code that blocks the first
invocation and lets the second client go through without obtaining
the lock instead of vice-versa (outlandish, I know). The second
client will now unlock sucessfully because you
did not uniquely identify the lock as long as RMI is using the same
thread pool for the second request. The poor first lock will finally
do it's thing and find that there is no lock to unlock!
Setting the thread name to something unique when the lock is obtained and checking for it in the unlock method will surface this bug properly.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Reza Rahman:
Thread name assigning/checking will stop this from happenning. In addition, it will give you three additional benefits:
1. Effectively disable the thick client issue, since you will have defeated the problems caused by thread pooling.
Originally posted by Reza Rahman:
[QB]2. Client's unlocking records they don't own.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Michal Charemza:
Is it ok to design my Data class that assumes that lock(), update(), and unlock() are all called from the same thread? This is to use the Thread.currentThread() to try to adhere to the spec for lock():
SCJP (77%)
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
SCJP (77%)
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by John Smith:
MC: Since a single RMI invocation will call book(), the call the lock(), update(), unlock() will all happen in the same thread.
Here is the story. When the next client calls book(), the execution may happen in the same RMI thread (the one used to execute book() for the first client). That is, RMI may choose to reuse the previous thread. A very tragic thing will happen -- the identities of two different clients will be mixed.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Reza Rahman:
I was curious from our discussion and did a bit more in-depth research on RMI thread handling. You are absolutely right, there cannot be two concurrent threads running with the same thread "identity" invoking remote methods.
Originally posted by John Smith:
Since the RMI spec doesn't prescribe which thread should be used for the remote methoods invocations, it's quite possible that the same thread will be used for two different clients. To make it even worse, it can happen during the two concurrent invocations.
<<snip>>
RMI temporarily dumps the state of thread T1 to disk, initializes it, and allocates that thread to client C2
<<snip>>
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
I do not have any "cookie" parameters specified, like others do. I could not use the connection objects in this class - so I am back to whether I can design Data to assume that lock(), update() and unlock() are called from the same thread. From all the discussion, I think that I must do - I have no alternative (whether I use the naming ID trick or not).
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Originally posted by Lara McCarver:
I don't have cookie parameters either, but it is still possible to distinguish the client who is calling on the server side... so long as each client gets its own Data object. Then, each Data object can have a unique generated ID... at least, that is my design.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
P.S.: Jokes aside, I wonder if making personal comments is appropriate to the general atmosphere of a forum hopefully full of professional (or would-be professional) developers (unless Lara happens to be your wife, girlfriend, sister, etc)...
SCJP 1.4, SCJD
Lara is out shopping
This design matches her beauty
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1