Java Reference
In-Depth Information
as either read or write and also specify time-out for methods that may block. With bean-
managed concurrency, it's up to you to use Java's concurrency features such as the
syn-
chronized
and
volatile
primitives or the
java.util.concurrent
API to man-
age concurrent access and ensure correctness.
An annotation is used to specify which concurrency management approach is being used.
If no annotation is provided, container-managed concurrency is assumed. This was the case
in
listing 3.3
. The annotation/parameter combinations are as follows for each concurrency
management method:
•
@ConcurrencyManage-
ment(ConcurrencyManagementType.BEAN)—
Bean concurrency man-
agement
•
@ConcurrencyManage-
ment(ConcurrencyManagementType.CONTAINER)—
Container concur-
rency management
The
@ConcurrencyManagement
annotation is to be placed on the bean class, not the
business interface:
@Target(value = {ElementType.TYPE})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface ConcurrencyManagement {
public ConcurrencyManagementType value() default
ConcurrencyManagementType.CONTAINER;
}
Container-managed concurrency
Container-managed concurrency is the default setting for singleton session beans. By
default, all bean methods are serialized via write locks. In the case of the
De-
faultFeaturedItem
in
listing 3.3
,
only one thread may execute the
getFeaturedItem
method at a time. This is obviously not what you want: if a thousand
clients are hitting the site at the same time, making each one of them wait to see the featured
item isn't a good idea for performance, not to mention sales. Two annotation combinations
are provided by the EJB specification, enabling you to tell the container what type of lock-
ing behavior you really want:
•
@Lock(LockType.READ)—
This method can be accessed concurrently while
no one holds a write lock on the bean.
