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 u

Answer 1

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.

Answer 2

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.