• 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 ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Contradiction in Head First EJB ?

Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello rangers,

it seems, there are two contradictions in the Head First EJB-book, but I'm not sure.

Page 325 describes:
How did the client get a reference to the EJBObject?
1. Client calls a finder on the home.
2. Client calls create on the home.
3. Client calls a home business method that returns a reference to the bean's component interface.

Page 346 describes:
Put code in your home business methods that apply to the underlying database - for a group of entities rather than one specific entity - and that don't return the bean's component interface (the way finders and create method must).

Does a home business method can return a component interface or not?

Page 348 describes:
Starting a business method (in a transaction)
1. Client calls getAddress() on the stub for entity bean #28.
2. The call is passed to the EJBObject.
3. The EJBObject gets the call and panics, because there is no entity bean for #28.
4. The Container sees that this method need a transaction, so the Container starts one, then pulls a bean from the pool, and calls ejbActivate() on the bean.

Page 354 describes:
The Container prefers (no, make that INSIST) that if you access a bean or a resource manager, you must be in a meaningful transaction context, so ejbActivate() is too early. But once you get to ejbLoad(), you're IN a transaction.

Page 348 explains, that the Container starts a transaction, pulls a bean from the pool and calls ejbActivate() on the bean. If this is true, the ejbActivate()-call occurs after the transaction-start, thus, we should be in a meaningful transaction context. But Page 354 explains, the call of ejbActivate() runs not in a meaningful transaction context. Which of this statements is correct?

Page 349 describes:
1. The Container calls ejbStore().
2. The real entity is updated in the database.
3. The Container commits the transaction and tells the database to unlock the entity.

I miss the ejbPassivate()-method. When does this call occur? After the update or after the commit?

Could anyone help me, please?

Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. I think EJB Home methods can return a component or home interface.
An ejbHome method is just like a business method on a session bean for example. You should probably only return remote versions of component/home interfaces in the remote component interface of the entity.

2. Good question. ejbActivate and ejbPassivate do indeed run in an unspecified tx. If you see the life cycle image in the spec, its seems logical to me that the transaction is started after ejbActivate has been called. After that ejbLoad and the business method are performed in the specified tx (ejbLoad prior to the business method

3. I think that there is no passivation required ? ejbStore is called when a transaction ended. This does not necesairly mean that the bean gets passivated. The container is in control of that.


For your question 3, ejbLoad is invoked after ejbActivate but before calling the business method. ejbStore is invoked before calling ejbPassivate. See spec 176.
You can also deduct this from the life cycle view. ejbLoad and ejbStore can only be performed while the instance is in 'method ready' state. ejbActivate/passivate trigger the transition to pooled. So its logical that ejbStore/ejbLoad must be executed before/after the state transition.
[ July 30, 2005: Message edited by: Koen Serneels ]
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Koen, thank you for your clarification.
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
my view is that for a cmp bean,
ejbLoad is called when it enters/begins transaction
and ejbStore when its' about to commit the transaction....
if you think brussel sprouts are yummy, you should try any other food. And this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic