EJB 3.1 container managed concurrency vs. synchronized

Question

I've started reading about the singleton session bean and the annotations used to employ container managed concurrency. I don't see the benfit of this compared to simply using the 'synchronized' keyword, so I suspect there is something important I am missing. Consider this example from the book "Enterprise JavaBeans 3.1" by Rubinger & Burke, O'Reilly:

@javax.ejb.Lock(javax.ejb.LockType.READ)
public String concurrentReadOnlyMethod(){...}

@javax.ejb.Lock(javax.ejb.LockType.WRITE)
public void allowOnlyOneWriteAtATimeMethod(String stringToSet){...}

How is this better than omitting the annotation all toghether in the read-case and using the synchronized keyword in the write-case, like this:

public String concurrentReadOnlyMethod(){...}

public synchronized void allowOnlyOneWriteAtATimeMethod(String stringToSet){...}

score 4 · Accepted Answer · answered Aug 24 '11 at 16:37

4

Simple.

The "concurrentReadOnlyMethod" is not synchronized at all, so it doesn't gain other side effect of synchronization (such as effects on variables within the memory model). Also, the READ lock will block the WRITE lock, so with just synchronized, you can have two threads running both methods simultaneously, whereas with the READ/WRITE lock you won't.

Obviously there's more value when you have several READ locks and few WRITE locks, as all of the READ locks can be shared and run simultaneously, while the WRITE locks act more like a normal synchronized.

answered Aug 24 '11 at 16:37

Will Hartung

115,893
19
128
203

1

If I understand you correctly, may I phrase it informally like this: Given one class containing both of the above methods, with container managed concurrency the semantics is "concurrent reads are allowed as long as no writing is going on". The semantics of the contrasting example will be "concurrent reads are allowed, also while writing goes on, but only one thread will be writing at a time". – Are Husby Aug 25 '11 at 18:08
Yea, that summarizes it pretty well. – Will Hartung Aug 25 '11 at 20:48
Can you give me a reference of this semantics of READ/WRITE lock in EJB 3.1? I could not find it even in the specification. – illEatYourPuppies Feb 05 '13 at 16:38
I think the semantics of READ/WRITE is also in the docs of the lock type (although very briefly) http://docs.oracle.com/javaee/6/api/javax/ejb/LockType.html – bennidi Mar 18 '13 at 13:56

score 2 · Answer 2 · answered Aug 24 '11 at 22:25

Well, as mentioned by Will, with synchronized you can't actually replicate the behavior of javax.ejb.Lock annotations, but you can actually do it by using ReadWriteLock locks, but this is more work in the end.

As a side note, since singleton instances are not shared across multiple JVMs (meaning they are not distributed objects), there are really no other benefits I can think of that Lock provides aside form ease of use and out of the box support.

Please also note that "If this annotation is not used, a value of Lock(WRITE) is assumed", so you can't really get rid of it either.

EJB 3.1 container managed concurrency vs. synchronized

2 Answers2

Linked