Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB Life Cycle

 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1868
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic