Re: [Ur] Exceptions handling

[Vladimir Shabanov]

2010/9/5 Adam Chlipala ad...@impredicative.com:
 I've started implementing this.  Everything works, save that the semantics
 differs between Postgres and MySQL/SQLite.  Postgres won't let you continue
 using a transaction after one command has failed, whereas MySQL and SQLite
 allow many errors within one transaction.  (Remember that every Ur/Web page
 execution is implicitly inside a single transaction.)  What does everyone
 think about whether that semantics is acceptable for Ur/Web?  The more
 liberal semantics can be implemented for Postgres using savepoints, but it
 would decrease performance.  If no one would want to keep running SQL after
 an error, then there doesn't seem to be a reason to do more work.

 Personally, I'm in favor of never using this new feature, anyway, but I'm
 interested in what y'all who argued for it think. :)

I think it would be nice to have possibility to manually restart
transaction so DB still can be accessed after error.

___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Exceptions handling

[Adam Chlipala]

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.


___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Exceptions handling

[Karn Kallio]

 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
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur