• 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

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

 
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Raf! You are really very helpful
 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone help on this?
 
Ranch Hand
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 856
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ?
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Raf, you are really helpful
 
Fire me boy! Cool, soothing, shameless self promotion:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic