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){...}

Answer 1

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.

Answer 2

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.