As Paul Sandoz said, the transaction must be available for rendering, if lazy
loading is used. Therefore @Transactional on resource methods is not the best
idea. Maybe I'll separate the transactional code, like you suggested. For now
I'll go with a simple Servlet Filter since it seems to work properly.
Christian
--
http://scala-forum.org/
>
>Von: Craig McClanahan <craigmcc@gmail.com>
>An: users@jersey.dev.java.net
>Gesendet: Mittwoch, den 11. August 2010, 19:23:41 Uhr
>Betreff: Re: [Jersey] Database Transactions with Jersey
>
>
>
>
>On Wed, Aug 11, 2010 at 1:50 AM, Christian Helmbold
><christian.helmbold@yahoo.de> wrote:
>
>
>>
>>2) Starting and committing or rolling back transactions around @Transactional
>>annotated resource methods with Guice AOP [3].
>>
>>
In my $DAYJOB environment, we have had a lot of success using Spring's AOP
transactional support in conjunction with the JAX-RS implementation we use
(happens to be Apache CXF, but this approach should work with Jersey as well).
Although it would be possible to use the transactional annotations directly on
the JAX-RS resource class methods, our preference is to separate all the
business logic into a separate tier that is also used by the HTML-generating
part of our application, so the transactional annotations are placed on that
tier's classes in our world. This percolates up to the JAX-RS resource class
level as things like "transaction rolled back" exceptions, which you can easily
process with things like JAX-RS exception mappers.
Craig