• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

7.6.3 -- Missed ejbRemove() calls and Release of Resources

 
Seid Myadiyev
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
______________________________________________________
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy,
I have a few thoughts on this...
The spec doesn't say anything about *how* you should free up resources that were not taken care of because of a missed ejbRemove() call. The exam expects you to know that it can happen -- i.e. that a passivated bean that times out will NOT be "reawakened" (activated) only to be KILLED -- it will simply go straight from passivation to total death.
And of course you have the same problem if there's a server crash.
If you are talking about normal Java resources, like a Socket, then the GC eventually takes care of it.
But if you do something the container is not involved with... like store something temporarily in a database (from a session bean), and IF your design involves deleting those things on ejbRemove(), then you have a problem. You cannot count on ejbRemove(), and that is what the exam wants you to know.
The spec doesn't say anything about HOW you would do that cleanup, so it is not on the exam.
A question on the exam might present you with a design / scenario, and you have to tell whether it is a good idea or not. If you SEE that a session bean is relying on ejbRemove() to be called, you KNOW that is not a good idea.
In the real world, we try to avoid doing anything in ejbRemove() unless we ALSO do it in ejbPassivate. This takes care of the scenario where the bean is passivated then killed. (but doesn't help us with a server crash).
Bert's other question is a little tricky because of the wording in the spec. When the spec says:
- To support more efficient vendor implementations leveraging lazy loading and dirty detection mechanisms; to reduce memory footprints; to avoid data aliasing problems... "
This means that a vendor CAN implement these features, and the spec has made it possible, but these features are NOT a guarantee to a bean developer.
When the exam says "guarantee" it means absolutely positively this is the way it works in EJB.
Lazy loading, dirty detection for CMP beans, etc. are up to vendor-specific implementations. If they aren't absolutely guaranteed...
The way to tell in the spec is to look for the word "MUST" as in, "The container MUST do..." or look for the word "guarantee" or "will always". Sometimes you have to look in several places, but it sounds like you are doing an excellent job with that
cheers,
Kathy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic