users@jersey.java.net

Re: [Jersey] Resource Management through nested sub-locators

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 09 Jun 2009 16:28:04 +0200

Another possibility is to support the injection of some transactional
context.

   @Context TransContext tc;

    rc.begin(new Trans() {
          void do() {
          }
       });

It sucks because of no closures in Java though :-(

Any exception thrown within the transaction results in rollback,
otherwise the commit could be queued up to be called after the
response is processed if the transaction is request scoped.

Paul.


On Jun 9, 2009, at 4:16 PM, Paul Sandoz wrote:

> On Jun 9, 2009, at 3:18 PM, Martin Probst wrote:
>
>>>> Yes, but which method did not finish,
>>>
>>> Essentially the application did not return a Response, namely a
>>> resource
>>> method did not finish (or was not called).
>>
>> OK, but how do I detect that, and where?
>
> I was assuming in this case that application would call commit in
> that case at the end of the resource method. Which is not particular
> good from an EOY perspective.
>
>
>> I might be missing something,
>> but browsing the code I cannot quite find a hook for that.
>
> There is no Jersey specific hook for that. One would need to use
> method-level interceptors e.g. provided by Spring or Guice for the
> case of the method was called but an exception was thrown in the
> method.
>
>
>> Also it
>> depends on when - the goal is to use Jersey to create e.g. a 500 page
>> through an ExceptionMapper, so there will be a response.
>>
>
> Right, but not a response returned from a resource method
> implemented by the application.
>
>
>> About the transaction guidelines: that sounds pretty much like what I
>> want to do. But there remains the problem that Jersey won't throw an
>> exception if one uses its ExceptionMapper to build nice error
>> messages. So if you use Jersey/JAX-RS for all stuff, you'll end up
>> with your transactions always committing. Shouldn't this be a
>> problem?
>>
>
> I think it depends how commit is called. For a servlet application
> if a transaction is open and the application does not call commit
> then the container will rollback. I do not know how things work if
> the servlet container opens the transaction, rather than the
> application.
>
> I am also wondering what this means for transactional support when
> say using Spring, i guess there could be an issue there if rollback
> is triggered by an exception, but some exceptions are mapped by
> Jersey...
>
> The only way i can currently think of doing this for managed
> transactions at the servlet level is to check:
>
> 1) For an exception that is not mapped by Jersey and is passed to
> Servlet; or
>
> 2) A status code of >= 500.
>
> And, if either of the above occur then rollback is performed,
> otherwise commit is performed.
>
> I do not think any exception mapping listening will be better, you
> might know that an exception was mapped but does that indicate that
> a rollback should be performed? not necessarily because an exception
> may be mapped to say a 400 client error due to a malformed response.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>