CODEWITHSUNDEEP
singletonejb-3.1concurrenthashmap
Jason H
Jason H

Reputation: 51

EJB3 Singleton Session Bean and ConcurrentHashMap

If using a EJB3 Singleton Session Bean, there is no point to having ConcurrentHashMap state variable - correct? I can just use a regular HashMap that will be managed by the Container Concurrency Manager ?

Upvotes: 3

Views: 1356

Answers (2)

Brett Kail
Brett Kail

Reputation: 33946

The default is @ConcurrencyManagement(CONTAINER) with @Lock(WRITE) for all methods, which won't scale as nicely as a ConcurrentHashMap since all method calls will block waiting for the write lock. You could use @Lock(READ) and ConcurrentHashMap to allow multiple threads, but at that point, you might as well use @ConcurrencyManagement(BEAN) to get rid of the container-managed concurrency altogether.

Upvotes: 3

Mikko Maunu
Mikko Maunu

Reputation: 42114

That is correct. If nothing else is specified, by default singleton session bean uses container managed concurrency. Further, if not specified, every business and timeout method have by default LockType.WRITE. Result is that there is not multiple threads concurrently executing methods in singleton and as consequence using regular java.util.HashMap is perfectly fine.

Upvotes: 3

Related Questions