> Vladimir Shabanov wrote: > > So savepoint will be introduced only where it really needed (dml with > > user error handling)? I think that this is the best solution. > > Yes, that's what I meant. > > > BTW it can be useful to have function for cancelling (and maybe > > restarting) transaction as a part of error handling. > > In Ur/Web, transactions are used for all state, not just the database. > I would want to have a reasonable integration of transaction restart > with all kinds of state, which can include arbitrary protocols thanks to > C FFI libraries. That would complicate the FFI, so I'll leave this out > for now. If a compelling use case comes up, let me know.
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. So I suppose with PostgreSQL, a use case could be any situation where Serializable isolation levels are called for. Transactions that include a mixture of complicated selects and updates will probably need the Serializable isolation level. An example could be some sort of reporting application where "presentation" tables are filled with results computed from "input" tables via multiple steps with several layers of tables holding intermediate results. If many users are concurrently adding data to the input tables and viewing the presentation tables Serializable would probably be necessary. Whenever two users input data that resulted in overlapping changes in an intermediate result table cancel/retry would have to be done. Reference: http://www.postgresql.org/docs/8.4/static/transaction-iso.html Section 13.2.2 _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
