Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Questions about Spring @Transactional annotation and EM's

Putting @Transactional over you service/dao class does this. Calling a
@Transactional method from another @Transactional method will join the
two transactions by default.

Mohsen.

On Tue, Feb 10, 2009 at 5:12 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> Thanks, that makes sense. I guess if I'm doing a set of operations on
> multiple entities in a transaction it should probably be in it's own
> DAO method just for business rules sake.
>
> I'm wondering if I can mark my whole class as being inside a
> transaction rather than a single method....
>
> ./tch
>
>
>
> On Tue, Feb 10, 2009 at 8:37 AM, James Sutherland <jamesssss@xxxxxxxxx> wrote:
>>
>> I'm no Spring expert, but assuming it behaves the same way as SessionBeans,
>> each transaction will have a new EntityManager.  So inside your delete, you
>> will need to re-find the object by its id then delete it.
>>
>>
>>
>> tch wrote:
>>>
>>> Ok,
>>> So I've finally gotten a few free seconds to start looking at Spring
>>> and JPA/EclipseLink again, and have started to run into some curious
>>> things.
>>>
>>> In this example I have a DAO that has 2 methods and an EM injected like
>>> this:
>>> @PersistenceContext
>>> private EntityManager entityManager;
>>>
>>> @Transactional(readOnly=true)
>>> find(..)
>>>
>>> @Transactional(propagation = Propagation.REQUIRED)
>>> delete(Object entity)
>>>
>>>
>>> So in my controller I inject the dao, then do something like this:
>>>
>>> Entity e = dao.find(..)
>>> dao.delete(e);
>>>
>>> EclipseLink cries and says it can't delete an unmanaged entity :/
>>>
>>> So apparently I'm confused about what exactly is happening when I use
>>> this @Transactional annotation. Admittedly I didn't read the docs too
>>> thoroughly, so I'm not surprised. My options are to do the find/delete
>>> in one @Transactional method or call a merge inside my dao's delete
>>> method. But I don't understand why I'm getting a (different?) em even
>>> though I'm using the same dao, in the same request. Does
>>> @Transactional do something funky with the em? Does it not guarantee
>>> the same one?
>>>
>>> Thanks and don't be afraid to reply with RTFM :)
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>>>
>>
>>
>> -----
>> ---
>> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
>> http://www.eclipse.org/eclipselink/
>>  EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
>> TopLink
>> Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
>> http://wiki.oracle.com/page/TopLink TopLink
>> Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
>> http://www.nabble.com/EclipseLink-f26430.html EclipseLink
>> Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
>> --
>> View this message in context: http://www.nabble.com/Questions-about-Spring-%40Transactional-annotation-and-EM%27s-tp21933061p21933759.html
>> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>


Back to the top