• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question on Reentrant Locking Behavior of Singleton Session Beans

 
Ranch Hand
Posts: 634
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Frits
 
My pie came with a little toothpic holding up this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic