On Jun 9, 2009, at 4:42 PM, Martin Probst wrote:
>> 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 :-)
>
Doh! keyboard dyslexia: i meant Ease Of Use.
>
>>> 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?
>
Not currently, although it is something we could add to the state of
the response.
>> 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 think I meant 412, in case of a versioning conflict.
The 4xx set of errors are associated with an error related into the
information the client has sent the server.
http://greenbytes.de/tech/webdav/rfc2616.html#status.412
The precondition given in one or more of the request-header fields
evaluated to false
when it was tested on the server. This response code allows the
client to place
preconditions on the current resource metainformation (header field
data) and thus
prevent the requested method from being applied to a resource other
than the one
intended.
Thus i do not think such status codes are appropriate to signal
rollback, or for an appropriate response to send to the client if
rollback occurred.
> I would identify these cases:
> * regular response is created and returned by the application ==>
> commit
> * application throws a WebApplicationException ==> commit
In the above two cases a 500 status might be returned.
>
> * application throws some sort of RuntimeException ==> call
> ExceptionMappers and have them indicate whether the request failed
>
It seems to be that the existing approaches of signaling rollback
using an exception do not really fit well with JAX-RS, and the use of
a 5xx status code is the better way to signal a rollback. BUT it may
not be compatible with existing solutions... although... IIRC Spring
uses AOP so any exception will be caught before it is mapped by Jersey
(BTW if you use NetBeans there is an example using Spring ,
transactions and DB access).
Aside from using AOP the only other solution I can think of is what I
previously sent and it is to utilize a closure and define that any
exception originating from the closure will result in rollback.
Paul.