![]() | |
| |
Release of Resources
When the container discards an instance because of a system exception, the container should release all the resources held by the instance that were acquired through the resource factories declared in the enterprise bean environment. For example, an object that implements the javax.sql.DataSource interface is a resource manager connection factory for java.sql.Connection objects that implement connections to a database management system.
NOTE: While the container should release the connections to the resource managers that the instance acquired through the resource factories declared in the enterprise bean environment, the container cannot, in general, release "unmanaged" resources that the instance may have acquired through the JDK APIs. For example, if the instance has opened a TCP/IP connection, most container implementations will not be able to release the connection. The connection will be eventually released by the JVM garbage collector mechanism.
Missed PreDestroy Calls for Session Beans
The Bean Provider cannot assume that the container will always invoke the PreDestroy lifecycle callback interceptor method(s) (or ejbRemove method) for a session bean instance. The following scenarios result in the PreDestroy lifecycle callback interceptor method(s) not being called for an instance:
A crash of the EJB container.
A system exception thrown from the instance's method to the container.
A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way.
If resources are allocated in a PostConstruct lifecycle callback interceptor method (or ejbCreate<METHOD> method) and/or in the business methods, and normally released in a PreDestroy lifecycle callback interceptor method, these resources will NOT be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.
For example, if a shopping cart component is implemented as a session bean, and the session bean stores the shopping cart content in a database, the application should provide a program that runs periodically and removes "abandoned" shopping carts from the database.
Missed PreDestroy Callbacks for Message-Driven Beans
The Bean Provider cannot assume that the container will always invoke the PreDestroy callback method (or ejbRemove method) for a message-driven bean instance. The following scenarios result in the PreDestroy callback method not being called on an instance:
A crash of the EJB container.
A system exception thrown from the instance's method to the container.
If the message-driven bean instance allocates resources in the PostConstruct lifecycle callback method and/or in the message listener method, and releases normally the resources in the PreDestroy method, these resources will NOT be automatically released in the above scenarios. The application using the message-driven bean should provide some clean up mechanism to periodically clean up the unreleased resources.
|
|
|
|
Hosting provided by PerfoHost: KVM VPS. Unix VPS. Windows VPS. VPN. Domains. Dedicated servers. Colocation.