users@jersey.java.net

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

From: Martin Probst <mail_at_martin-probst.com>
Date: Tue, 9 Jun 2009 16:42:17 +0200

> 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.

Excuse my ignorance - EOY? I guess you didn't mean Entrepreneur Of the
Year or End Of Year, but I can't find another explanation :-)

>> 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.

I'd rather not go into AOP territory here - I think I'd need to hook
on more or less private methods in Jersey's implementation, and that
is certainly not a good idea.

>> 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.

Is there a way for user code to notice the difference?

> 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...

Yes, that's what I'm aiming at. An automated transaction manager would
expect the application to signal an error in user code by throwing an
exception, which triggers the rollback. In the JAX-RS case, there is
no exception thrown out of Jersey's servlet.

> 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.

That's a difficult thing to decide.

I'd argue that if the user code does not throw a subclass of
WebApplicationException, but rather uses an exception mapper, that
should mean an error occurred as I'd think of the ExceptionMapper as a
last resort thing. However you're right that there may be a lot of
cases where you just want to translate your own, non-critical
exception into a web status.

Maybe instead of making such assumptions, it should be possible
somehow for the application to signal to the framework whether it
considers the request to have failed so that a transaction would need
rollback. For example, an application might want to rollback for a 409
status code in case it only found out about the conflict after making
some changes to the database.

I would identify these cases:
* regular response is created and returned by the application ==> commit
* application throws a WebApplicationException ==> commit
* application throws some sort of RuntimeException ==> call
ExceptionMappers and have them indicate whether the request failed

Martin