• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Question on Reentrant Locking Behavior of Singleton Session Beans

 
Ranch Hand
Posts: 634
Eclipse IDE Chrome 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" ?
 
Creator of Enthuware JWS+ V6
Posts: 3346
303
Android Eclipse IDE Chrome
  • 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
Eclipse IDE Chrome 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
Posts: 3346
303
Android Eclipse IDE Chrome
  • 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
Eclipse IDE Chrome 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
Posts: 3346
303
Android Eclipse IDE Chrome
  • 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
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Frits
 
Anything worth doing well is worth doing poorly first. Just look at this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic