Karn Kallio wrote:
In PostgreSQL, use of the Serializable transaction isolation level
will give
failures whenever for example a transaction selects a set of rows and another
concurrent transaction modifies some before the query finishes.
These serialization failure errors generally need the application to cancel
and retry the transaction.
Yes, thanks for pointing this out; I've been aware of it, and I think
the Postgres database module already treats this correctly. That is,
the transaction conflict error code is singled out and triggers
automatic restart of the current page generation. This rolls back all
externally-visible side effects, including those done with the C FFI (if
these C libraries use the Ur/Web runtime system API correctly).
The implementation I'm working on for error-returning [dml] retains the
automatic restart behavior for serialization failures, only returning
error codes to the program in other cases.
Vladimir Shabanov wrote:
2010/9/6 Adam Chlipala<[email protected]>:
> Vladimir Shabanov wrote:
>>
>> Do you mean that things like "set my_source new_value" will also roll
>> back on transaction error?
>>
>
> In server-side code, yes. Client-side code isn't really transactional,
> despite the misleading use of the [transaction] monad. On the server side,
> examples of FFI state to roll back include e-mails queued to be sent and
> manual filesystem changes.
Nice thing. I didn't thought that anything except DB transaction is
cancelled on error. This should be documented somewhere (maybe in
demo).
I think the documentation for C function uw_register_transactional()
already explained this, but let me know if you think some change is
warranted.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
