Hi Tim, I just have the one provided by aries in my system, and it seems to work. At least my objects do get persisted. But somehow this effect is not really reproducable, I'm quite sure I did see the same Exception as mentioned in this thread [1]. Now after a couple of "reboots" of Karaf I don't see this anymore. Right now I'm suspecting that this might be related to be only an issue with a "clean" run. I'm gonna try as soon as my system is not in "dev-mode" anymore :D
regards, Achim [1] - http://karaf.922171.n3.nabble.com/Exception-No-transaction-currently-active-td4025308.html 2012/7/27 Timothy Ward <[email protected]>: > A few thoughts: > > Do you have more than one Transaction Manager in your system, and if not does > the one you have work? It can lead to all manner of unpleasant inconsistency > if the blueprint tx and JPA bundles disagree about the state of the current > transaction. > > Are there any warnings/exceptions from the proxy code or blueprint when > creating your bean? This could lead to the interceptor not being called > properly. > > Also, could you send the stack trace of the exception? > > Tim > >> Date: Thu, 26 Jul 2012 22:58:36 +0200 >> From: [email protected] >> To: [email protected] >> Subject: Re: Aries JPA container managed with no active transactions >> >> OK, >> >> well I did engage this exception with a simple setup that looks like this: >> >> <bean id="serviceBean" >> class="de.nierbeck.test.blueprint.jpa.MyServiceImpl"> >> <jpa:context unitname="store" property="entityManager" /> >> <tx:transaction method="*" value="Required" /> >> </bean> >> >> <service ref="serviceBean" >> interface="de.nierbeck.test.blueprint.jpa.MyService" /> >> >> No much voodoo magic there, still I did receive those >> TransactionRequiredExceptions. Any thoughts? regards, Achim >> >> >> Am 26.07.2012 22:40, schrieb Timothy Ward: >> > These methods throw a TransactionRequiredException because the JPA spec >> > defines that they must when called outside a transaction. >> > >> > Regards, >> > >> > Tim >> > >> >> Date: Thu, 26 Jul 2012 15:49:42 +0200 >> >> Subject: Re: Aries JPA container managed with no active transactions >> >> From: [email protected] >> >> To: [email protected] >> >> >> >> Looking at the code, it seems that some methods *have* to run inside a >> >> transaction, mostly non read-only methods (lock / refresh / persist). >> >> I've no idea why is that needed though, not sure it's really related to >> >> any >> >> synchronization issue. >> >> >> >> On Thu, Jul 26, 2012 at 3:42 PM, Achim Nierbeck >> >> <[email protected]>wrote: >> >> >> >>> hmm, interesting. >> >>> So this might be related to what a user has reported during this week? >> >>> >> >>> >> >>> http://karaf.922171.n3.nabble.com/Exception-No-transaction-currently-active-td4025308.html >> >>> >> >>> and actually I have seen this also .... >> >>> >> >>> regards, Achim >> >>> >> >>> 2012/7/26 Jean-Baptiste Onofré <[email protected]>: >> >>>> Agree. >> >>>> >> >>>> Thanks for the update. >> >>>> >> >>>> Regards >> >>>> JB >> >>>> >> >>>> >> >>>> On 07/26/2012 03:33 PM, Guillaume Nodet wrote: >> >>>>> Actually, given the Entity Manager is not thread safe, I'd rather >> >>> consider >> >>>>> that a bug and synchronize access to it inside the JTAEntityManager by >> >>>>> wrapping the detachedEntityManager into a delegate object with all >> >>> methods >> >>>>> synchronized. >> >>>>> This would ensure that no concurrency issues will happen. >> >>>>> >> >>>>> On Thu, Jul 26, 2012 at 2:12 PM, Guillaume Nodet <[email protected]> >> >>> wrote: >> >>>>>> It seems that when using JPA in container managed mode, an entity >> >>> manager >> >>>>>> is bound to the transaction. >> >>>>>> However, when no transactions is active, a single shared entity >> >>>>>> manager >> >>>>>> is >> >>>>>> used. >> >>>>>> Unless I'm wrong, the EntityManager is not thread safe, so all >> >>>>>> requests >> >>>>>> to >> >>>>>> the DAO that are not inside a transaction will reuse the same entity >> >>>>>> manager, and may run into concurrency issues such as OPENJPA-1716 >> >>>>>> Shouldn't aries print a warning at least in such cases ? >> >>>>>> >> >>>>>> -- >> >>>>>> ------------------------ >> >>>>>> Guillaume Nodet >> >>>>>> ------------------------ >> >>>>>> Blog: http://gnodet.blogspot.com/ >> >>>>>> ------------------------ >> >>>>>> FuseSource, Integration everywhere >> >>>>>> http://fusesource.com >> >>>>>> >> >>>>> >> >>>>> >> >>>> -- >> >>>> Jean-Baptiste Onofré >> >>>> [email protected] >> >>>> http://blog.nanthrax.net >> >>>> Talend - http://www.talend.com >> >>> >> >>> >> >>> -- >> >>> >> >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >> >>> Committer & Project Lead >> >>> OPS4J Pax for Vaadin >> >>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >> >>> Lead >> >>> blog <http://notizblog.nierbeck.de/> >> >>> >> >> >> >> >> >> -- >> >> ------------------------ >> >> Guillaume Nodet >> >> ------------------------ >> >> Blog: http://gnodet.blogspot.com/ >> >> ------------------------ >> >> FuseSource, Integration everywhere >> >> http://fusesource.com >> > >> >> >> -- >> ----- >> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
