This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

question 15 HF pg 366

 
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
 
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().
 
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.
 
Villains always have antidotes. They're funny that way. Here's an antidote disquised as a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!