Building business logic with session beans - EJB 3 in Action - page 87

5 . Executes the requested business method invoked through the business interface by
the client.
6 . When the business method finishes executing, the bean is placed back in the
“method-ready” pool (if the container supports pooling). If the container doesn't sup-
port pooling, the bean is discarded.
7 . As needed, the container retires beans from the pool.
As mentioned previously, stateless session beans are extremely performance-friendly. A re-
latively small number of bean instances can handle a large number of virtually concurrent
clients when pooling is used.
If you look carefully, you'll see that the stateless session bean lifecycle ensures that all bean
instances are accessed only by one request thread at a time. This is why stateless session
beans are completely thread-safe and you don't have to worry about synchronization con-
cerns at all, even though you're running in a highly concurrent server environment!
A stateless session bean has two callbacks with the following annotations:
• @PostConstruct— This is invoked immediately after a bean instance is created
and set up and all resources are injected.
• @PreDestroy— This is invoked right before the bean instance is retired.
If needed, multiple methods in a bean class can be annotated with these lifecycle callbacks.
Listing 3.1 uses both the @PostConstruct and @PreDestroy callbacks in the ini-
tialize and cleanup methods, respectively. These callbacks are typically used for al-
locating and releasing injected resources that are used by business methods. This is exactly
what's happening in listing 3.1 —you open and close connections to the database using the
injected JDBC data source. The question might arise as to why you can't perform both of
these operations using the constructor and the finalize method. Well, when the con-
structor is instantiated none of the resources have been injected yet, so all of the references
will be null. As for the finalize method, its use is actively discouraged and it's meant
more for closing out low-level resources such as JNI references. It's never to be used for
closing out database connections. The finalize method is invoked long after the bean
has left the pool and is in the process of being garbage collected.