Re: em.find outside of a JTA transaction
Why should it not be allowed? There are even samples for a PersistenceContext producer field in the CDI spec. They are not EXTENDED though. Btw not sure what you want to achieve with it... That one is pretty easy to explain. By default when working without DTOs but with plain entities on the frontend you need to em.merge() the entity on any postback because otherwise lazy loading and navigation would not work. But this has the side effect that changes in the entity automatically get stored in the database - even if the user didn't want to because he didn't yet press the 'Save' button. By using an unsynchronized transaction context and explicitly call em.joinTransactio() when in the save() action, all the changes in the DB only happens when the user really likes to store it. All the trick with the EntityManager producer is just to make sure there is no synchronized transaction attached to the EM on the postback. got me? LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@tomee.apache.org Cc: Sent: Tuesday, 25 June 2013, 17:37 Subject: Re: em.find outside of a JTA transaction Hi Mark You produce an extended em, that's not allowed i think (i didnt say it is forbidden). Btw not sure what you want to achieve with it... Le 25 juin 2013 17:13, Mark Struberg strub...@yahoo.de a écrit : Hi! According to the spec all read operations on an EntityManager should work and only write operations must be queued up until em.joinTransaction() gets called. Is this correct? Maybe I have an error in my sample, but I get a nasty Exception in my sample. https://github.com/struberg/jta_test just mvn clean install java.lang.IllegalStateException: InternalError: an entity manager should already be registered for this extended persistence unit at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManager(JtaEntityManagerRegistry.java:99) at org.apache.openejb.persistence.JtaEntityManager.getEntityManager(JtaEntityManager.java:91) at org.apache.openejb.persistence.JtaEntityManager.find(JtaEntityManager.java:164) at org.apache.webbeans.custom.persistence.EntityManager$$OwbNormalScopeProxy0.find(javax/persistence/EntityManager.java) at at.struct.jpatest.CustomerService.loadCustomer(CustomerService.java:56) at at.struct.jpatest.CustomerService$$OwbNormalScopeProxy0.loadCustomer(at/struct/jpatest/CustomerService.java) at at.struct.jpatest.StoreTest.assertSurName(StoreTest.java:67) at at.struct.jpatest.StoreTest.testCustomerLifecycle(StoreTest.java:41) LieGrue, strub
Re: em.find outside of a JTA transaction
hmm, aren't you used to produce your own em instead of using a container one? whatever you can use a stateful directly to achieve it but you can't produce an extended em. The spec is not that clear about it, it says the extended em is bound to the stateful. You can still wrap your calls in the stateful (call(Callable)) but it is a bit less elegant. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/26 Mark Struberg strub...@yahoo.de Why should it not be allowed? There are even samples for a PersistenceContext producer field in the CDI spec. They are not EXTENDED though. Btw not sure what you want to achieve with it... That one is pretty easy to explain. By default when working without DTOs but with plain entities on the frontend you need to em.merge() the entity on any postback because otherwise lazy loading and navigation would not work. But this has the side effect that changes in the entity automatically get stored in the database - even if the user didn't want to because he didn't yet press the 'Save' button. By using an unsynchronized transaction context and explicitly call em.joinTransactio() when in the save() action, all the changes in the DB only happens when the user really likes to store it. All the trick with the EntityManager producer is just to make sure there is no synchronized transaction attached to the EM on the postback. got me? LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@tomee.apache.org Cc: Sent: Tuesday, 25 June 2013, 17:37 Subject: Re: em.find outside of a JTA transaction Hi Mark You produce an extended em, that's not allowed i think (i didnt say it is forbidden). Btw not sure what you want to achieve with it... Le 25 juin 2013 17:13, Mark Struberg strub...@yahoo.de a écrit : Hi! According to the spec all read operations on an EntityManager should work and only write operations must be queued up until em.joinTransaction() gets called. Is this correct? Maybe I have an error in my sample, but I get a nasty Exception in my sample. https://github.com/struberg/jta_test just mvn clean install java.lang.IllegalStateException: InternalError: an entity manager should already be registered for this extended persistence unit at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManager(JtaEntityManagerRegistry.java:99) at org.apache.openejb.persistence.JtaEntityManager.getEntityManager(JtaEntityManager.java:91) at org.apache.openejb.persistence.JtaEntityManager.find(JtaEntityManager.java:164) at org.apache.webbeans.custom.persistence.EntityManager$$OwbNormalScopeProxy0.find(javax/persistence/EntityManager.java) at at.struct.jpatest.CustomerService.loadCustomer(CustomerService.java:56) at at.struct.jpatest.CustomerService$$OwbNormalScopeProxy0.loadCustomer(at/struct/jpatest/CustomerService.java) at at.struct.jpatest.StoreTest.assertSurName(StoreTest.java:67) at at.struct.jpatest.StoreTest.testCustomerLifecycle(StoreTest.java:41) LieGrue, strub
Re: em.find outside of a JTA transaction
Effectively the producer method is the same like having a method getEm() in my @Stateful The EM is imo still bound to the @Stateful but it is _used_ outside of it. I gonna rewrite the sample to use the Stateful as interceptor. But I fear it will still not work. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: dev@tomee.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Wednesday, 26 June 2013, 9:10 Subject: Re: em.find outside of a JTA transaction hmm, aren't you used to produce your own em instead of using a container one? whatever you can use a stateful directly to achieve it but you can't produce an extended em. The spec is not that clear about it, it says the extended em is bound to the stateful. You can still wrap your calls in the stateful (call(Callable)) but it is a bit less elegant. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/26 Mark Struberg strub...@yahoo.de Why should it not be allowed? There are even samples for a PersistenceContext producer field in the CDI spec. They are not EXTENDED though. Btw not sure what you want to achieve with it... That one is pretty easy to explain. By default when working without DTOs but with plain entities on the frontend you need to em.merge() the entity on any postback because otherwise lazy loading and navigation would not work. But this has the side effect that changes in the entity automatically get stored in the database - even if the user didn't want to because he didn't yet press the 'Save' button. By using an unsynchronized transaction context and explicitly call em.joinTransactio() when in the save() action, all the changes in the DB only happens when the user really likes to store it. All the trick with the EntityManager producer is just to make sure there is no synchronized transaction attached to the EM on the postback. got me? LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; dev@tomee.apache.org Cc: Sent: Tuesday, 25 June 2013, 17:37 Subject: Re: em.find outside of a JTA transaction Hi Mark You produce an extended em, that's not allowed i think (i didnt say it is forbidden). Btw not sure what you want to achieve with it... Le 25 juin 2013 17:13, Mark Struberg strub...@yahoo.de a écrit : Hi! According to the spec all read operations on an EntityManager should work and only write operations must be queued up until em.joinTransaction() gets called. Is this correct? Maybe I have an error in my sample, but I get a nasty Exception in my sample. https://github.com/struberg/jta_test just mvn clean install java.lang.IllegalStateException: InternalError: an entity manager should already be registered for this extended persistence unit at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManager(JtaEntityManagerRegistry.java:99) at org.apache.openejb.persistence.JtaEntityManager.getEntityManager(JtaEntityManager.java:91) at org.apache.openejb.persistence.JtaEntityManager.find(JtaEntityManager.java:164) at org.apache.webbeans.custom.persistence.EntityManager$$OwbNormalScopeProxy0.find(javax/persistence/EntityManager.java) at at.struct.jpatest.CustomerService.loadCustomer(CustomerService.java:56) at at.struct.jpatest.CustomerService$$OwbNormalScopeProxy0.loadCustomer(at/struct/jpatest/CustomerService.java) at at.struct.jpatest.StoreTest.assertSurName(StoreTest.java:67) at at.struct.jpatest.StoreTest.testCustomerLifecycle(StoreTest.java:41) LieGrue, strub
Fwd: svn commit: r1496862 - /tomee/tomee/trunk/container/openejb-core/pom.xml
Hi Andy, we need to provide something (so scope runtime or compile) otherwise no log will work in tests/standalone at least. Since we log most of our messages with JUL slf4j-jdk14 seems fine. What's the issue? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* -- Forwarded message -- From: andygumbre...@apache.org Date: 2013/6/26 Subject: svn commit: r1496862 - /tomee/tomee/trunk/container/openejb-core/pom.xml To: comm...@tomee.apache.org Author: andygumbrecht Date: Wed Jun 26 09:52:46 2013 New Revision: 1496862 URL: http://svn.apache.org/r1496862 Log: Scope Modified: tomee/tomee/trunk/container/openejb-core/pom.xml Modified: tomee/tomee/trunk/container/openejb-core/pom.xml URL: http://svn.apache.org/viewvc/tomee/tomee/trunk/container/openejb-core/pom.xml?rev=1496862r1=1496861r2=1496862view=diff == --- tomee/tomee/trunk/container/openejb-core/pom.xml (original) +++ tomee/tomee/trunk/container/openejb-core/pom.xml Wed Jun 26 09:52:46 2013 @@ -556,11 +556,13 @@ dependency groupIdorg.slf4j/groupId artifactIdslf4j-jdk14/artifactId + scopeprovided/scope /dependency !-- Dependency of Quartz -- dependency groupIdorg.slf4j/groupId artifactIdslf4j-api/artifactId + scopeprovided/scope /dependency dependency groupIdxmlunit/groupId
