• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What does really happens during SFSB passivation?

 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, we know that during Stateful Session bean passivation, the container saves the bean in a sort of secondary storage to save resources between method invocations; this may be serialization.

I thought that the container may do something like the following, and I would like you to confirm what I think:

1) The container can have a pool of stateful session beans
2) When the SFSB is in the method ready state, its state reflects a conversational state with a unique client
3) When the container decides to passivate the bean, its state can be saved with something that acts as serialization, BUT THE BEAN THEN CAN BE PUT INTO THE POOL, READY TO SERVE ANOTHER CLIENT.
4) When the container receives a business method invocation for a SFSB that it passivated, it retrieves the serialized state, it TAKES OUT A BEAN OF THAT TYPE FROM THE POOL, it assigns the serialized state to the bean, and it invokes the business method on the bean.

5) THOUGH PHISYCALLY THE CLIENT HAS BEEN SERVED BY TWO DIFFERENT SFSBs, at his eyes IT HAS BEEN SERVED ONLY BY ONE, because it's the state that matters, not the actual physical object that contains it.

Am I correct? Is this something that is possible but is vendor specific?
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BUT THE BEAN THEN CAN BE PUT INTO THE POOL, READY TO SERVE ANOTHER CLIENT.


I dont think same session bean are allowed to serve 2 different clients, even when the are passivated.

in the spec 7.6.1, it says that the container CAN replace the following during ejbActivate(), but functionality identical
1. Object reference to JNDI and subcontents
2. An object reference to UserTransaction
3. Object reference to sessionContext

I cant find it in the specs for allowing a different bean, but on page 85 of Mastering E-Javabeans, it states: "Note that the bean that reeives the activated state may not be the original bean intance"
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ryan Wong:



in the spec 7.6.1, it says that the container CAN replace the following during ejbActivate(), but functionality identical
1. Object reference to JNDI and subcontents
2. An object reference to UserTransaction
3. Object reference to sessionContext

I cant find it in the specs for allowing a different bean, but on page 85 of Mastering E-Javabeans, it states: "Note that the bean that reeives the activated state may not be the original bean intance"


This validates my theory that a bean instance can be reused, provided that the client keeps its original state.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic