aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Stateful Beans / Passivation / Extended Persistence Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Stateful Beans / Passivation / Extended Persistence" Watch "Stateful Beans / Passivation / Extended Persistence" New topic
Author

Stateful Beans / Passivation / Extended Persistence

Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
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


SCJP 6 - SCJD - SCWCD 5 - SCBCD 5
JavaEnterpriseEditionFaq - TomcatFaq
amit punekar
Ranch Hand

Joined: May 14, 2004
Posts: 515
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
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
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
Ranch Hand

Joined: May 14, 2004
Posts: 515
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
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
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
Ranch Hand

Joined: May 14, 2004
Posts: 515
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Stateful Beans / Passivation / Extended Persistence