I recently had a test case where a GET that fails leaves the system in a bad state. e.g. a following DELETE couldn't upgrade its lock.
That seems to be resolve now.
Thanks, Stefan
Oliver Zeigermann wrote:
OK, I have done this now.
In Domain.xml in the config section there now is a parameter "all-methods-in-transactions" that is switched on by default. If you want the old behavior reset it to "false".
Oliver
Oliver Zeigermann wrote:
I can imagine scenarios where starting a transaction can be very expensive. For those I would opt to have a switch in Domain.xml that can re-enable reads outside of transactions.
Oliver
Oliver Zeigermann wrote:
Folks!
Presently certain request methods (like GET) do not work inside of a transaction.
With reads not inside of transactions the GET method may return corrupt data (although permanently nothing will be inconsistent) and no writes, e.g. to create a new user with user autocreation, can be done along with this request.
The pro is that internal locks will be held for a shorter period of time and there is no transactional overhead involved.
I opt for having all methods inside of transactions. The change to achieve this is trivial and can even be part of the upcoming beta.
What about you?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
