@PreDestroy as the name suggests is called when the container wants to get rid of the instance and wants to notify the bean that it is doing so. PreDestroy can be called in the method ready state.
In the case of a stateless session bean -
- if the processing has got completed and it is no longer required.
If its a stateful session bean then -
@PreDestroy happens as soon as the @Remove method gets completed.
Thursday, July 3, 2008
APIs that all EJB 3.0 containers must make available to developers
Java 2 Platform, Standard Edition v5 (J2SE) APIs, which include the following APIs:
JDBC
The EJB container must include the JDBC 3.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.
RMI-IIOP
An enterprise bean's remote business interfaces and/or remote home and remote interfaces are remote interfaces for Java RMI. The container must ensure the semantics for passing arguments conforms to Java RMI-IIOP. Non-remote objects must be passed by value.
Specifically, the EJB container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean's semantics. Any local optimizations of remote interface calls must ensure the semantics for passing arguments conforms to Java RMI-IIOP.
An enterprise bean's local business interfaces and/or local home and local interfaces are local Java interfaces. The caller and callee enterprise beans that make use of these local interfaces are typically collocated in the same JVM. The EJB container must ensure the semantics for passing arguments across these interfaces conforms to the standard argument passing semantics of the Java programming language.
JNDI
At the minimum, the EJB container must provide a JNDI API name space to the enterprise bean instances. The EJB container must make the name space available to an instance when the instance invokes the javax.naming.InitialContext default (no-arg) constructor.
The EJB container must make available at least the following objects in the name space:
The business interfaces of other enterprise beans.
The resource factories used by the enterprise beans.
The entity managers and entity manager factories used by the enterprise beans.
The web service interfaces used by the enterprise beans.
The home interfaces of other enterprise beans.
ORB objects
UserTransaction objects
EJBContext objects
TimerService objects
JAXP
Java IDL
EJB 3.0 APIs, including the Java Persistence API
The container must implement the semantics of the metadata annotations that are supported by EJB 3.0
The container must implement (or provide through a third-party implementation) the javax.persistence interfaces and metadata annotations.
JTA 1.1, the UserTransaction interface only
The EJB container must include the JTA 1.1 extension, and it must provide the javax.transaction.UserTransaction interface to enterprise beans with bean-managed transaction demarcation through the javax.ejb.EJBContext interface, and also in JNDI under the name java:comp/UserTransaction, in the cases required by the EJB specification.
JMS 1.1
The EJB container must include the JMS 1.1 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level interfaces that are intended for integration of a JMS provider with an application server, not for direct use by enterprise beans.
JavaMail 1.4, sending mail only
JAF 1.1
JAXP 1.2
JAXR 1.0
JAX-RPC 1.1
JAX-WS 2.0
JAXB 2.0
SAAJ 1.3
Connector 1.5
Web Services 1.2
Web Services Metadata 2.0
Common Annotations 1.0
StAX 1.0
Subscribe to:
Posts (Atom)