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.