Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question on Reentrant Locking Behavior of Singleton Session Beans

 
Mohit G Gupta
Ranch Hand
Posts: 634
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Source EJB 3.1 Specification


4.8.5.1.1 Reentrant Locking Behavior

Special locking semantics apply to loopback calls on Singletons with container-managed concurrency.

If a loopback call occurs on a Singleton that already holds a Write lock on the same thread :

1. If the target of the loopback call is a Read method, the Read lock must always be granted
immediately, without releasing the original Write lock.
2. If the target of the loopback call is a Write method, the call must proceed immediately, with-
out releasing the original Write lock.


Please let me know if my understanding of the below statements is correct or incorrect:

Statement:"the Read lock must always be granted immediately, without releasing the original Write lock"
Explanation: Loopback call is granted Read Lock and it can perform whatever read operation it wants to perform and this will not effect the Write Lock acquired by the Bean.

Please Let me know the answer for the following questions:

Statement:If the target of the loopback call is a Write method, the call must proceed immediately, with-out releasing the original Write lock.
Question1:How can container allow the loopback call(target write method) to be process as the Singleton already holds a Write lock on some thread ?

This seems opposite of what has been stated in
Topic 4.8.5.1
If the container invokes a method associated with a Write lock, no other concurrent invocations will be allowed to proceed until the initial Write method’s processing completes.


Question2:What is the difference between "granting a read or write lock to a loopback call " & "allowing a lookback call to process immediately" ?
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question1: How can container allow the loopback call(target write method) to be process as the Singleton already holds a Write lock on some thread ?

The container sees that the thread that wants to have a write lock on the Singleton already has a write lock on the same Singleton object and therefore grants access
If the container invokes a method associated with a Write lock, no other concurrent invocations will be allowed to proceed until the initial Write method's processing completes
This just means that no other thread (then the one that has a write lock) can continue

Question2:What is the difference between "granting a read or write lock to a loopback call " & "allowing a lookback call to process immediately" ?

This is a subtle difference in language. My interpretation is that in "granting a read lock" when it allready has a "write lock" means that there will be two locks on the same Singleton object whereas "allowing a lookback call to process immediately" means it will continue without setting a second write lock. Nevertheless it comes down to the same behaviour: the loopback call is allowed by the container.

Regards,
Frits
 
Mohit G Gupta
Ranch Hand
Posts: 634
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If a loopback call occurs on a Singleton that already holds a Write lock on the same thread :

2. If the target of the loopback call is a Write method, the call must proceed immediately, with-
out releasing the original Write lock.


The container sees that the thread that wants to have a write lock on the Singleton already has a write lock on the same Singleton object and therefore grants access


Question1:Its the Singleton that holds write or read lock OR its the thread ?

If a loopback call occurs on a Singleton that holds a Read lock on the same thread ( but does not also
hold a Write lock on the same thread :
1. If the target of the loopback call is a Write method, a javax.ejb.IllegalLoopback-
Exception must be thrown to the caller.


Question2:Why cant the loopback call(target: Write method) be allowed to process ?

I don't see any issues if Singleton that holds a Read lock grants a write lock to the caller as there no other method running that is performing a read operation

 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question1:Its the Singleton that holds write or read lock OR its the thread ?

It is the client thread that puts a write-lock on the Singleton

Question2:Why cant the loopback call(target: Write method) be allowed to process ?

Other (client-)threads are allowed to perform a read when there is a read lock. If you would grant the write operation to execute the read operations would get an unpredictable result

Regards,
Frits
 
Mohit G Gupta
Ranch Hand
Posts: 634
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question1:Its the Singleton that holds write or read lock OR its the thread ?

It is the client thread that puts a write-lock on the Singleton


I understand your statement but the below text in specification tends to create confusion:

If a loopback call occurs on a Singleton that already holds a Write lock on the same thread

Does it mean that "if loopback call occurs on Singleton and the loopback call already holds a write lock on the same thread " ?

 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"if loopback call occurs on Singleton and the loopback call already holds a write lock on the same thread " ?

Yes that is correct, just rephrasing it a little bit: "if loopback call occurs on a Singleton and the originating client thread already holds a write lock on the same Singleton...."

Regards,
Frits
 
Mohit G Gupta
Ranch Hand
Posts: 634
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Frits
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic