Java Reference
In-Depth Information
will run once every day at midnight to load the featured item
. The EJB timer will be
covered in
chapter 5
—it isn't specific to singleton beans.
As you can see, singleton session beans are very similar to stateless session beans. The one
difference is that only one instance is created and that one instance serves all clients. Let's
take a closer look at the
@Singleton
annotation.
3.4.3. Using the @Singleton annotation
The
@Singleton
annotation marks the
DefaultFeaturedItem
POJO as a singleton
session bean. Other than marking a POJO to make the container aware of its purpose, the
annotation doesn't do much. The specification of the
@Singleton
annotation is as fol-
lows:
@Target(value = {ElementType.TYPE})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface Stateless {
public String name() default "";
public String mappedName() default "";
public String description() default "";
}
The definition of this annotation is no different from stateless and stateful session beans.
The
name
parameter specifies the name of the bean. Containers use this parameter to bind
the EJB to the global JNDI tree. The
name
field is optional and will default to the simpli-
fied name of the bean if not specified. The
mappedName
field is a vendor-specific name
that you can assign to your EJBs; some containers, such as GlassFish, use this name to as-
sign the global JNDI name for the EJB. The description is for documenting the bean for
use by tools and containers.
3.4.4. Singleton bean concurrency control
Because multiple consumers access singleton beans at the same time, concurrency is of
paramount performance. Singleton concurrency support comes in two flavors: container-
managed concurrency and bean-managed concurrency. The default setting if none is spe-
cified is container-managed concurrency. With container-managed concurrency, the con-
tainer synchronizes method calls. Annotations are provided so that you can mark methods
