Dear Kathy, Bert and all
EJB Developers,
May I request you to explain whether or not resources get released by the container.
If they do then -- how and in which scenarios specifcially?
Do resources get released by the container or by the JVM garbage collector mechanism?
Does this happen in all beans?
What does this mean:
"... the application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources."
Below I have 3 statements from EJB Specs 2.0 and 1 question (and explanantion) from Bert that relate to my question.
Thank you very very much!
+Seid
7.6.3 Missed ejbRemove() calls
The Bean Provider cannot assume that the Container will always invoke the ejbRemove() method on
a session bean instance. The following scenarios result in ejbRemove() not being called on 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 speci-
fied by the Deployer in an EJB Container implementation specific way.
If the session bean instance allocates resources in the ejbCreate<METHOD>(...) method and/or
in the business methods, and normally releases the resources in the ejbRemove() 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.
______________________________________________________
18.3.7 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 (See Subsection 20.4).
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.
______________________________________________________
1 Which two are guaranteed capabilities of EJB 2.0?
a). Local home interfaces for messages driven beans.
b). Dirty detection mechanisms to reduce memory footprints.
c). Run-as security identity functionality.
d). The
JDBC 2.0 extension.
e). Read only CMP entity beans.
#1, answers are: c, d
Perhaps answer b should be elaborated: In the EJB 2.0 spec, pages 25 and 26: "The new container-mananged persistance mechanisms are added to provide the following functionality:
- To support more efficient vendor implementations leveraging lazy loading and dirty detection mechanisms; to reduce memory footprints; to avoid data aliasing problems... "
PAGE 25-26.
1.2 What is new in EJB 2.0
-- We have revised Enterprise JavaBeans container-managed persistence for entity beans, and
have added support for container-managed relationships. We have specified new contracts for
entity beans with container-managed persistence to address the limitations of the field-based
approach to container-managed in persistence in earlier versions of the Enterprise JavaBeans
specification. The new container-managed persistence mechanisms are added to provide the
following functionality:
-- To support container-managed relationships among entity beans.
-- To provide the basis for a portable finder query syntax.
-- To support more efficient vendor implementations leveraging lazy loading and dirty
detection mechanisms; to reduce memory footprints; to avoid data aliasing problems;
etc.
______________________________________________________