[Ur] Exceptions handling

[Adam Chlipala]

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<adamc at impredicative.com>:
>    
>> >  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.