aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes EntityTransaction.begin();  and  EntityTransaction.commit(); Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "EntityTransaction.begin();  and  EntityTransaction.commit();" Watch "EntityTransaction.begin();  and  EntityTransaction.commit();" New topic
Author

EntityTransaction.begin(); and EntityTransaction.commit();

Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Please look at the code fragment below: (source: MZ notes)



It uses an application-managed EntityManager (through the factory, i.e. "emf")

I confused by the getTransaction().begin() and getTransaction().commit() statements.
Is it mandatory to use those two statements? If yes, is it mandatory only for application-managed EntityManagers or every EntityManagers?


This is what I thought about this. Please correct me if I'm wrong.
Using a EntityTransaction.begin() is not required here, because this is an application managed EntityManager. It is mandatory required only if we use a container-managed transaction, with the PersistenceContextType.TRANSACTION type. Otherwise, begining a transaction is not mandatory. Am I correct?
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Persist and a few other method must always be called within a transaction. For aplication-managed entity managers that are resource-local, the transaction is EntityTransaction. Yes, it is mandatory here.
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Thanks Raf! You are really very helpful
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Raf Szczypiorski wrote:Persist and a few other method must always be called within a transaction. For aplication-managed entity managers that are resource-local, the transaction is EntityTransaction. Yes, it is mandatory here.


Confused with that. Lifetime of the PersistenceContext, on an application-managed EntityManager should be handled manually by using EntityManager.close() method. Am I correct?
If it is, I couldn't figure out that why it is mandatory to begin a transaction before calling to the persist() method. Does it always need an active transaction? But, for what?

Please help on this.


Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Can someone help on this?
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844

Confused with that. Lifetime of the PersistenceContext, on an application-managed EntityManager should be handled manually by using EntityManager.close() method. Am I correct?
If it is, I couldn't figure out that why it is mandatory to begin a transaction before calling to the persist() method. Does it always need an active transaction? But, for what?

Please help on this.




yes it should be handled manually.

Yes persist() always need a active transaction. Otherwise it would throw transaction required exception.
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Amandeep Singh wrote:
Yes persist() always need a active transaction. Otherwise it would throw transaction required exception.


The JavaDoc says that

JavaDoc wrote:TransactionRequiredException will be thrown if invoked on a container-managed entity manager of type PersistenceContextType.TRANSACTION and there is no transaction.


In that case, an extended persistence context doesn't require an active transaction. So, why application-managed EntityManager do require it?
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Treimin Clark wrote:
Amandeep Singh wrote:
Yes persist() always need a active transaction. Otherwise it would throw transaction required exception.


The JavaDoc says that

JavaDoc wrote:TransactionRequiredException will be thrown if invoked on a container-managed entity manager of type PersistenceContextType.TRANSACTION and there is no transaction.


In that case, an extended persistence context doesn't require an active transaction. So, why application-managed EntityManager do require it?


how you conclude an extended persistence context doesn't require an active transaction ?
Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
Thanks for the excellent question (It made me realize how little I knew about EntityManagers and Transactions).

I found this link that kind of discusses the persist operation, please refer to section 5.5.1 of http://codeidol.com/java/netbeans/Persistence-EntityManager/Interacting-with-an-EntityManager/



Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Extended contexts don't need transaction for method calls as they preserve the entities between method invocations, possibly across many transactions. When you persist with extended context, the entity is added to the managed entities set, and is kept there, and it is only flushed when the transaction finally commits. So, in the end, you still need an active transaction to actually save anything to the database, even for extended contexts. Here is a piece of text from the specs on this (section 3.3, page 53):

When an EntityManager with an extended persistence context is used, the persist, remove, merge, and
refresh operations may be called regardless of whether a transaction is active. The effects of these oper-
ations will be committed to the database when the extended persistence context is enlisted in a transac-
tion and the transaction commits.

Resource-local context (that uses EntityTransaction) is always extended according to this (page 53):

The scope of the persistence context of an application-managed entity manager is extended. It is the
responsibility of the application to manage the lifecycle of the persistence context.

So I would say it doesn't require an active transaction when persist() is called, but it will need it anyways at the end to actually persist something. This code worked for me (Glassfish, tested with Toplink and Hibernate):

When you omit the begin / commit, and call em.close(), the sql to get a sequence value is executed when persist() is called, but the insert will never happen. So, to answer the original question: I would say that it is not necessary (not using the transaction will not throw an exception) for reading for extended (application and container extended contexts), but having an active transaction will eventually be necessary to store / update something.
For JTA-contexts, JTA is required, and persist() would throw an exception.

Raf
Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
Thanks for the explanation. Can you explain your last statement a little bit

For JTA-contexts, JTA is required, and persist() would throw an exception. I think you meant to say For JTA-contexts, transaction is required, and persist() would throw an exception.

If you are using a container manager entitymanager something like this

@PersistenceContext(type=PersistenceContextType.EXTENDED)
EntityManager entityManager;

Do you need a transaction to call persist() in this case (more specifically, will the call to persist throw an exception or not). Reading the javadoc for persist method, it does not look like we need a transaction. (I do understand the point you were trying to make, that you may call persist outside of a transactiion in some cases but the update will not make it to the DB unless there is a transaction)
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
I meant transaction is needed, that's right. And for an extended context, you do not need an active transaction to make the call. Extended contexts can either be container-managed, which always use JTA, or application-managed, which may use JTA or EntityTransaction (resource-local). In the example code above I am using EntityTransaction because I configured the unit to be RESOURCE_LOCAL, but I could have made it JTA, and it would work the same way, except that instead of EntityManager.getTransaction() I would use joinTransaction().
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Thanks Raf, you are really helpful
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: EntityTransaction.begin(); and EntityTransaction.commit();