"Leslie P. Polzer" <[email protected]> writes: > Jan Rychter wrote: > >> I've just hit a problem, as I have a transaction that I know will >> sometimes fail and can be safely retried (see my blog post >> http://jan.rychter.com/enblog/2009/6/6/postgresql-transactions.html for >> details). Unfortunately, as weblocks encloses every request in a giant >> transaction, my transaction has no effect, as they can't be nested. And >> I'd venture a guess that just retrying the whole-request-transaction is >> a bad idea, as there are plenty of side effects all over the code, >> rendering being one of them. >> >> Do we need more fine-grained transaction control? > > Why can't you use a Postgres savepoint?
Because I didn't know such a thing existed :-) But now that I do I can answer your question. Savepoints are for convenience, not error handling. An error aborts the entire transaction and there is no way to get back to your last savepoint: psql=# begin transaction; BEGIN psql=# update ratings set rating=1 where author_id=1 and talk_id=209; UPDATE 1 psql=# savepoint test_savepoint; SAVEPOINT psql=# insert into ratings values (1,209,5,0); ERROR: duplicate key value violates unique constraint "ratings_author_id_key" psql=# select * from ratings; ERROR: current transaction is aborted, commands ignored until end of transaction block psql=# rollback to savepoint; ERROR: no such savepoint psql=# rollback; ROLLBACK psql=# The more I think about it, the more I am convinced that per-request transactions are a bad idea. In case of CLSQL stores, if something goes wrong they will leave your database in a consistent state, but your model will most likely not agree with the database anymore, because we don't have STM like Clojure does. To put it another way, your perform updates to your model, and call persist-object to store your updates. If the database rejects your changes (due to violated constraints for example, or a race condition when using SERIALIZABLE isolation level), you normally have no way of restoring your model to the state from the beginning of the transaction. And this means is that the current way of doing things in Weblocks is broken. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
