• 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

EntityBean Life Cycle and ejbSelect(), ejbFind

 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Kathy,
The diferrent ways you can elaborate when an entity bean comes from a Ready state to a Pooled state and the in between container call back methods. And in which all case i can invoke the ejbSelect and ejbFinder methods.
Rishi
SCJP,SCWCD,IBM/OOAD
 
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 - I think this is a little too much for me to put in one post... but I'll try for some of it. The Container moves the bean to a pooled state whenever, well, whenever the Container wants to! The Container has three options for what to do after a transaction commits:
1) Call ejbPassivate() then send the bean back to the pool, where it stops having an identity
2) Leave the bean in the ready state, *associated* with a particular entity (in other words, linked to an EJB object with a specific primary key, like, Fred Jones #42), but without keeping the bean synchronized with underlying *real* entity in the database. This means that when a client calls a business method on the bean, it will get a new ejbLoad() call, but it skips the ejbActivate() since its already active.
3) Leave the bean in the ready state, as above, but keep it synchronized with the underlying entity. That way, when the client calls a method, the Container is ready to go -- no ejbActivate(), no ejbLoad().
#2 is perhaps the most common and efficient, although some Containers allow you to specifically tune things to use option #3, but of course this means that you are locking any other application out of the database, and so this would work only if you can guarantee that the only way to get to the database is through the bean, so it's OK to keep the database row (or whatever locking is used) locked continuously for that entity.
However, even with #2, the Container should usually have enough 'smarts' to decide when its appropriate and efficient to send a bean back to the pool (perhaps because nobody has called a business method on this entity for quite a long time...)
What we know FOR SURE is that ejbPassivate() is called when the bean moves to the pool from the ready state, UNLESS it is after an ejbRemove(). So, there are really TWO ways to get 'back' to the pool from the ready state:
1) ejbPassivate() (at the end of a tx, or whenever the Container wants to after a tx commits)
OR
2) ejbRemove() -- when a bean is removed, the Container will *not* call ejbPassivate(); the bean goes straight to the pool after ejbRemove().
A bean can never call its own finders, but the Container will call a finder method while the bean is STILL IN THE POOL. Remember, to run a finder, the bean does NOT need to leave the pool and *become* some specific entity.
ejbSelect methods are another story. These can be called by a bean WHILE STILL IN THE POOL, if they're used with a home business method. OR, they can also be called while the bean is executing a business method as a specific entity (in other words, a business method from the component interface, thus the bean is definitely OUT of the pool and acting as a particular entity (Fred Jones #42 as opposed to Carol Foo #56)
Hope that helps...
There's a ton of pictures of all this in the book
cheers,
kathy
 
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Entity Lifecycle
Move from pooled state to ready state will call
1. ejbActivate();
2. ejbLoad();
Move from ready state to pooled state will cal
1. ejbStore();
2. ejbActivate();
all right ?
Can i do " In ejbActivate and ejbPassivate method " ?
help me please.
thank you for all answer.
 
Kathy Sierra
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,
here are the things you can do in ejbActivate() and ejbPassivate(), for an entity bean:
Use your EntityContext to:
* get a reference to your home
* get a reference to your EJB object
* get your primary key
You CANNOT get security info about the client
You CANNOT force a transaction to rollback (you're already out of a tx at this point) by calling setRollbackOnly()
You CANNOT find out if the transaction has been set to rollback by calling getRollbackOnly()
Access:
* Your JNDI environment
You CANNOT invoke methods on another bean
You CANNOT access your resource manager (like a database connection)
=======================
And in ejbLoad() and ejbStore()
Use your EntityContext to:
* get a reference to your home
* get a reference to your EJB object
* get your primary key
* get security info about the client
* call setRollbackOnly()
* call getRollbackOnly()
Access:
* Your JNDI environment
* another bean's methods
* a resource manager
Cheers,
Kathy
 
I hired a bunch of ninjas. The fridge is empty, but I can't find them to tell them the mission.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic