Java Reference
In-Depth Information
@Target(value = {ElementType.TYPE})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface DependsOn {
public String[] value();
}
This annotation is placed on the bean class and takes one or more names of singleton ses-
sion beans that must be instantiated first. The order of the dependencies in the list isn't
maintained—this means that if a bean is annotated with
@DependsOn(A,B)
, you can't
depend on
A
being instantiated before
B
.
B
should have its own
@DependsOn
annotation
and specify that it expects
A
to be instantiated. The
@DependsOn
annotation ties nicely
into the
@Startup
annotation.
3.4.7. @Startup annotation
One of the key features of singleton session beans is the ability to have them auto-start
when the application is deployed. To mark a singleton session bean as being auto-instan-
tiated, all you need to do is add the
@Startup
annotation to the bean. The annotation is
defined as follows:
@Target(value = {ElementType.TYPE})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface Startup {
}
The annotation itself has no parameters. This is merely a marker that the container exam-
ines. When the container goes to instantiate a singleton bean with this annotation, it first
instantiates any singleton beans on which the bean depends. There are some ramifications
to this that we discuss in the next section.
3.4.8. Using stateful singleton session beans effectively
Stateful singleton session beans are an incredibly useful feature of EJB 3.1. Before you run
off and put them to use, there are some important things to remember about them. First,
because there's only one instance, they can be a performance bottleneck if they're used in-
correctly. Second, using container-managed concurrency doesn't absolve you from config-
uring the concurrency behavior. Just as garbage collection doesn't free you from managing
memory (RAM isn't limitless), container-managed concurrency isn't a magical solution to
