aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Aries JPA container managed with no active transactions
Date Fri, 27 Jul 2012 08:32:05 GMT
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 <timothyjward@apache.org>:
> 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: bcanhome@googlemail.com
>> To: dev@aries.apache.org
>> 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: gnodet@gmail.com
>> >> To: dev@aries.apache.org
>> >>
>> >> 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 <bcanhome@googlemail.com>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é <jb@nanthrax.net>:
>> >>>> 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 <gnodet@gmail.com>
>> >>> 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é
>> >>>> jbonofre@apache.org
>> >>>> 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/>

Mime
View raw message