• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Head First EJB Chapter 6, question 15

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Head First EJB Chapter 6, question 15 (pages 366/371) asks which methods are always invoked in direct response to a client operation, and the answer says that ejbCreate() and ejbRemove() are, and ejbLoad(), ejbACtivate(), ejbPassivate() and setEntityContext() are not.
At the moment I don't understand when ejbActivate() is called other than as a direct result of a client request. It's called when the bean moves out of the pool to the method ready state - doesn't this mean that it is as the result of a client request? Does the bean move to the method ready state for other reasons?
The note with the answer on page 371 says that Load, Passivate and setEntityContext can be called by the Container when it wants to, but it doesn't mention anything about ejbActivate().
[ February 05, 2004: Message edited by: Colin Richardson ]
 
Colin Richardson
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anybody offer any help on this? Page 172 and 175 of the spec says that ejbActivate() is called when the bean instance is taken from the pool and assigned a specific identity. Does this ever happen other than as a result of a client operation?
There's probably something obvious about ejbActivate() that I'm not seeing, but I wonder if the answer in HFEJB is correct? I've checked the errata on oreilly.com and there's nothing mentioned, and I also did a search on this forum to see if I could find any previous questions on the same subject, but again didn't find anything. This suggests that it must just be that I've missed something obvious...
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy -- this is a good question Colin, and it's confusing because we don't really explain what "as a direct result" means.
When we say "as a direct result", that means the method is invoked because the client called a corresponding method in an interface. Even ejbActivate() can be called whenever the Container wants to... although you're right, most of the time it is called because the client invoked a business method that starts a new transaction. But the Container can do whatever it wants with activation and passivation behind the scenes. Unlike stateful session beans, an entity bean can be passivated even while it's in a transaction. So, even in the course of one transaction triggered by one initial call from the client, there could be activation/passivation going on (the bean always gets the ejbStore() before passivation, though... that much IS guaranteed.)
So, we want you to separate out the ones that are *always* triggered as a DIRECT result of a client call from the ones that *might* be triggered as the direct result of a client call. It's the word "direct" that matters, but I agree that this is confusing because we didn't define what we really mean by "direct", and ejbActivate() is a fuzzy area, but just remember that what the Container does behind the scenes is anything the Container wants to do... as long as the behavior is synchronized with the database properly.
When you see "direct" think, ALWAYS invoked as opposed to MIGHT be invoked. If client calls a business method, or any other method on a bean, there is never a guarantee that the other intermediate methods are called (including ejbActivate and ejbLoad).
But I think your point was that even if it isn't called EVERY time, the times when it IS called are always a result of a client invocation, right? That's how it looks, yes. But in the spec (page 169) it gives the Container flexibility to do whatever it wants there. I should have pointed this out more specifically... your conclusion is completely reasonable!
So when you see "as a direct result" think only of the things which are ALWAYS invoked (unless the Container refuses for security reasons or errors) and you should be safe. If something might or might not be invoked as part of the underlying process of getting the bean ready, then don't include it as a direct result.
Hope that helps,
Kathy
 
Colin Richardson
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kathy,
Once again, thanks for another great answer. It's much appreciated.
Colin
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Colin,

I think on HFB book P.356 ("Commit Option A and B"), that mentioned a situation that ejbActivate() was not called when client called the bean operations.

Kathy,


Unlike stateful session beans, an entity bean can be passivated even while it's in a transaction



Is it one of the possible case ?

Bean A may be passivated when it's in a transaction. Am I correct ?
reply
    Bookmark Topic Watch Topic
  • New Topic