• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

question 15 HF pg 366

 
Miki Muzsi
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which methods are invoked in direct response to a client operation?

1. ejbLoad()
2. ejbCreate()
3. ejbRemove()
4. ejbActivate()
5. ejbPassivate()
6. setEntityContext()

Valid answers (in the book) are 2 and 3. My question is why is not ejbActivate() good as well? SInce that is invoked as a consequence to a direct operation, when the client invokes a business method.

Or can it be that a bean is activated for other reasons as well? Without the client triggering the activation?

Miki
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ejbActivate() is not always invoked in response to a client request, unlike ejbCreate() and ejbRemove(). This is true for both stateful session beans and entity beans. And an entity bean can be passivated even while it is in a transaction (unlike stateful session beans). So, even in the course of one transaction triggered by a client request, there could be a series of activation and passivation taking place under the covers.
 
Miki Muzsi
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger, if I understand you correctly, you say that during one business method call the bean can be activated and passivated? Did you read this in the spec? If yes where? I don't remember reading this, which would obviously explain the answer.

And If I am thinking a bit with loud voice ... I am wondering why should the container ever do this? It seems very inneficient and it doesn't seem to make sens. Pasivation of an entity bean means that the bean goes back in the pool, and it doesn't represent anymore an entity from the database. If he does this during a business method (so before the method finishes) where/how does he store the information that the bean refers to that specific entity which he has to represent when he becomes active?

Miki
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger, if I understand you correctly, you say that during one business method call the bean can be activated and passivated? Did you read this in the spec? If yes where? I don't remember reading this, which would obviously explain the answer.

A component business call on an entity bean will require an activation of an entity bean instance and a passivation after the end of the method. It's in the OID.

And If I am thinking a bit with loud voice ... I am wondering why should the container ever do this? It seems very inneficient and it doesn't seem to make sens. Pasivation of an entity bean means that the bean goes back in the pool, and it doesn't represent anymore an entity from the database. If he does this during a business method (so before the method finishes) where/how does he store the information that the bean refers to that specific entity which he has to represent when he becomes active?

Every EJB container has its own way of deciding when to passivate an instance. In the case of entity beans, the container can choose (by some means or other) to passivate an instance within a transaction. To passivate an instance, the container first invokes the ejbStore() method to allow the instance to synchronize the database state with the instance�s state, and then the container invokes the ejbPassivate() method to return the instance to the pooled state. Subsequently, the container will invoke ejbActivate() followed by ejbLoad() to enable the bean's state to be synchronized again with the database. At the end of the transaction, there will be an ejbStore() followed by an ejbPassivate().
 
sawan parihar
Ranch Hand
Posts: 250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An entity bean instance could move between the Pooled and Ready states many times in its lifetime, and could be associated with different primary keys at different points. At any given point in time, however, an entity bean instance is associated with at most one primary key - it is associated with no primary key if it is in the Pooled state, and is associated with one primary key if it is in the Ready state.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic