File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes EJB Life Cycle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB Life Cycle" Watch "EJB Life Cycle" New topic
Author

EJB Life Cycle

Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

I'll be quick because I had to type this twice.

Is this a true statement: "unsetEntityContext is not guaranteed to be called immediately after a call to ejbRemove"

In other words, the container may chose to completely remove the EJB from the pool of available beans, or it may chose to simply leave it there.

In the tutorial it mentions set/unsetEntityContext as a method to perform database connections. It occurs to me that the EJB instance may not be completely removed for some time, and thus leave an open connection to the database.

Any comments?
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1836

unsetEntityContext is not guaranteed to be called immediately after a call to ejbRemove

I think that this is in reference to the fact that after removing a bean the bean looses its identity with reference to the entity objects representation in the database. It will be put back in the pool. Thus the unsetEntityContext is not immediately called. It is ready to service another client. However if there are already adequate instances in the pool greater than the stipulated pool size then the unsetEntityContext is called and the bean is removed.

There are subtle but distinct differences between the ejbRemove() and the unsetEntityContext(). Most of them can be found out by reading the EJB specs 1.1 page 105 and 106 which are
unsetEntityContext
1. invoked with unspecified transaction context
2. Identity of bean is unavailable during this method
3. Bean is in the pooled state
ejbRemove
1. Bean is in the ready state
2. executes in the transactin context determined by the transaction attribut4e of the remove method that riggere the ejbRemove method
3. the instance can obtain the identy of the entity object via the getPrimaryKey() or the getEJBObject()

It occurs to me that the EJB instance may not be completely removed for some time, and thus leave an open connection to the database.

I think that you have associated remove with "does not exist state" of the entity bean which is not correct while removing a bean puts it into the "pooled" state. There are three states of the entity bean which are The "does not exist state" , "pooled" and the "ready" state. refer page 102 of the ejb 1.1 spec.
Note : In a session bean however the ejbRemove() method puts the session bean in the "does not exist" state. refer ejb 1.1 specification page 57 and page 69
It is possible to open connections both in the ejbCreate(..) and in the setEntityContext(). It is done at the setEntityContext and the unsetEntityContext() when resource which cannot be specific to an entity object identity are needed to be allocated.
[This message has been edited by Rahul Mahindrakar (edited April 17, 2001).]
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

I think that you have associated remove with "does not exist state" of the entity bean which is not correct while removing a bean puts it into the "pooled" state.
Not at all, it was just a really bad choice of word (removed). I should have said "It occurs to me that the EJB instance may not be 'made eligible for garbage collection' for some time..."

Thanks for your reply.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EJB Life Cycle
 
Similar Threads
unSetEntityContext()
Manually delete entity bean in memory?
Finalize() method in the bean class
mock question
unsetSessionContext