Stateful Beans / Passivation / Extended Persistence

[Bob Wheeler]

Short question:
From the Enthuware test I have the following statement marked as true:

"A stateful session bean cannot be passivated if it is in a transaction."

Does this mean, that in an extended transaction a stateful bean will never be passivated unless the @Remove method is called?

Thank you.
Bob

[amit punekar]

Hi,
AFAIK this condition would happen if the bean uses bean managed transactions. In this a method would start a transaction but leave it open to be committed by another method. Due to this the container will not passivate the SFSB instance as it would still be servicing the client.
As per the core Ejb specs a client to such bean should take care not to call remove method.
See 4.4.4 ejb core specs.
Pl correct if this understanding is wrong.
Thanks,
Amit

[Bob Wheeler]

Hi Amit,

thanks for your answer.

amit punekar wrote:Hi,
AFAIK this condition would happen if the bean uses bean managed transactions. In this a method would start a transaction but leave it open to be committed by another method. Due to this the container will not passivate the SFSB instance as it would still be servicing the client.

Why should it only happen in a BMT (bean managed transaction)? The extended persistence context could be also used with a CMT (container managed transaction). Or, do I mix something?

amit punekar wrote:
As per the core Ejb specs a client to such bean should take care not to call remove method.
See 4.4.4 ejb core specs.

I guess you mean this paragraph:

If a session bean instance is participating in a transaction, it is an error for a client to invoke the
remove method on the session object’s home or component interface object. The container
must detect such an attempt and throw the javax.ejb.RemoveException to the client.
The container should not mark the client’s transaction for rollback, thus allowing the client to
recover.

Now you have me at a complete loss. I thought that an extended context maintains its managed objects between transactions and all objects accessed or created hang around until the bean goes away. Which means until the @Remove method is called. Now, that should result in an exception. I am confused

Cheers,
Bob

[amit punekar]

Hi Bob,
I replied BMT for the term "Extended Transaction" that you mentioned in your first email.
Extended persistence Context can be used in Stateful beans alone using EntityManagerFactory. The transaction and Persistence Context are different from each other. In Container Managed Entity Manager, by default Persistence context starts and ends with the JTA transaction. Whereas in SFSB if we inject the EntityManagerFactory and then use Extended persistence context, then you the entities remain in "Managed" state in between transactions.
Coming back to what EJB Specs say about @Remove, it says it about the Transactions that spans across multiple Bean methods(Of course this is possible only in Bean Managed Tx and Stateful Session bean). So EJB Core spec that I pointed out in earlier post, does not talk about Extended Persistence Context.
Of course this is my understanding after reading the specs and EJB Oreily book. I haven't yet had any chance to work with the JPA specs.
Hope this helps you. Someone more knowledgeable might want to correct if this is wrong.

Thanks,
Amit

[Bob Wheeler]

amit punekar wrote:
The transaction and Persistence Context are different from each other.

Thanks for your answer. I sort of mixed transaction and persistence context.

Cheers
Bob

[amit punekar]

Hi,
I was also kind of confused about this. I was also referring Enthuware for preparation of SCBCD exam.
I gave the exam last week itself so answering this question helped me to clarify my concept too.
Thanks,
amit