On Jun 9, 2009, at 11:52 AM, Martin Probst wrote:
> Pondering this a bit more and looking through the code, I noticed that
> the actual Response is not constructed until after all the matching
> has happened.
Correct.
The response is serialized to the servlet, then any per-request
resource instances are destroyed and any Closeable instances are closed.
Maybe it is sufficient for your application to detect if commit has
not been called (i.e. the method did not finish) and if so rollback is
performed ? thus it is up to the application if they throw an
exception to decide whether a commit should be performed. Then it
should be possible to do such work in the Closeable.
Another approach is to:
1) clearly define the HTTP status codes on which rollback must be
performed if a commit
has not already occurred;
2) define a mode in JAX-RS/Jersey that never passes exception to
servlet.
I think the latter fits better in the style of JAX-RS i.e. key things
of the HTTP status code.
Paul.
> So if one needs the session/resource/whatever to be
> still open during the response building, this method will not work as
> the ScarceThing will be closed after matching has happened. This again
> probably depends on your use case, but if e.g. you're returning a
> response that will be lazily built/streamed, this won't work (I'm
> aware that Jersey will close streams, but there are other cases). So
> this throws me back with a servlet filter checking if Servlet.service
> throws an exception or not as the only solution, as I do now.
>
> The way I see this error handling/resource management is that I want
> to allocate resources and reliably free them. Beyond that, I also want
> to be notified if request handling did not complete normally, i.e. by
> throwing an unexpected exception that is neither handled within the
> user code, nor a WebApplicationException or MappableContainerException
> (I think, for the latter I'm not sure about its uses), so that I can
> run a compensation action (rollback).
>
> So this is possible for the resource management part by implementing a
> servlet filter that will catch unhandled exceptions, and registering
> allocated resources with that filter so that it can handle them with
> rollback/commit correctly. But this happens outside of Jersey, so I
> cannot use the nice Response.build features and similar. Also, if
> someone implements an ExceptionMapper for some exception, she will
> either need to tell the filter that the request still failed (if that
> is the case), or we'll end up committing things that shouldn't be.
>
> This could probably be solved by having an ErrorListener (not handler,
> just listener) that will be notified if a request failed under the
> aforementioned terms. Kind of like an ExceptionMapper<T>, but with the
> different semantics that it's not consuming the error (so that all
> listeners will be notified) and not constructing a response (which
> would be left to the mappers).
>
> This is getting more complex than I had anticipated - I guess it's a
> trade off between the elegance of JAX-RS and the simplicity of plain
> servlets where you'd simply have the try/finally construct.
>
>> I am not sure, I am guessing it is if the "method" (Servlet.service
>> or an EJB method) does not complete (i.e. throws an exception).
>
> So pretty much as I do now, but sadly you loose the nice error
> handling features of Jersey that way. It might also be a bit
> unanticipated by users - if you have an
> ExceptionMapper<WorldHasAbruptlyEnded>, your database session will be
> committed even though this might not have been intended by the user -
> maybe he just wanted to create a more legible error message.
>
> I guess it's quite hard to make decisions in that area, but an
> unambiguous way to communicate to the outside/framework that this
> request has failed would probably be nice. I'm not sure how many
> people actually really care about this, but I can see people getting
> bitten by this.
>
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>