> The 4xx set of errors are associated with an error related into the
> [412] 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 don't agree. I can imagine a server side implementation accepting a
request, performing some work, then checking the preconditions,
detecting the precondition failure, and then using rollback to undo
any changes performed. That's a really nice use case for transactions,
if you can't do that, they won't be of much help.
>> 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.
Yes.
>> * 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.
I don't agree. Requiring a 500 code if you want a rollback and "piggy
backing" the information that a database rollback is required on top
of the status code is in my opinion a really bad idea. This is a
massive constraint as to when server side implementations may use
rollback, or it will force people to use 500 codes in situations where
they are really not appropriate, just to get the rollback.
Remember that transaction rollbacks do not need to be the consequence
of an internal server error. There are lots of cases where you happily
code to expect some condition and use a rollback to compensate for
earlier work. This is the key feature of a transactional database
system.
> 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.
The closure will not work as it would not include the entire request
handling, but only the location step handling.
I might be a bit repetitive here, but the thing that would work would
be allowing the user to install/inject some class that will always get
notified if an unhandled exception occurred during request processing
(and that should include writing the response). You could either have
a dedicated "ExceptionListener" or extend the ExceptionMapper somehow,
but the first one is probably cleaner. Is there anything that speaks
against this?
Martin