On Wed, Feb 15, 2012 at 10:26:50AM -0800, Mike Orr wrote: > On Wed, Feb 15, 2012 at 8:47 AM, Marius Gedminas <mar...@gedmin.as> wrote: > > On Tue, Feb 14, 2012 at 03:16:00PM -0800, Jonathan Vanasco wrote: > >> I recently learned that pyramid_tm closes the session on a > >> transaction.commit() > >> > >> I also learned that either transaction or pyramid_tm automatically > >> commits at the end of a request > >> > >> I'm not comfortable with either of these behaviors, particularly the > >> latter > >> > >> I've run into too many situations where my ability to continue in the > >> application logic depends on if a transaction committed to disk or > >> not. > > > > Nothing prevents you from performing a transaction.commit() in your > > application code. > > > >> I'm also not too comfortable with migrating a lot of legacy code to > >> savepoints as suggested in this discussion : > >> https://groups.google.com/forum/#!msg/pylons-discuss/5Mj4R3YMXhI/GVFj2Du33JAJ > >> > >> ( btw, thanks to Eric Rasmussen for pointing that out to me ). > >> > >> I just read the paragraph about the transaction 'feature' in the intro > >> ( > >> http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/introduction.html?highlight=commit > >> ) , and I can see how many people would enjoy this behavior - but its > >> a bit too much magic for me. I'm porting a legacy app from Pylons to > >> Pyramid, and there are chunks of code which use both savepoints and > >> multiple transactions within a request.. and its going to be quite > >> cumbersome to move the logic to this idiom. > >> > >> Aside from these two features, which are unarguable beneficial to a > >> certain audience, are there any elements of transaction/pyramid_tm > >> that I'd miss ? > > > > Automated rollback if an exception happens at any point during > > transaction processing? > > > > The ability to commit to multiple databases with a transaction.commit()? > > > > The ability to install custom transaction data managers that perform > > externally visible actions (sending emails, logging entries) only during > > a successful commit? > > > > The facility for retrying requests on transaction conflicts? Certain > > databases -- ZODB, PostgreSQL in the strictest transaction isolation > > levels -- handle transaction conflicts by raising an exception that > > requires the app to replay the entire transaction manually. pyramid_tm > > can be configured to do that for you (this is off by default). > > But conversely, if you don't need these features, you don't have to > use pyramid_tm. > > I didn't know transaction.commit() recreated the session, or that it > could retry the transaction.
No, no, transaction.commit() cannot do that. pyramid_tm can do that, according to the documentation. > I'm surprised about the retrying and > somewhat skeptical about it, because how can it capture and reissue > the SQL commands that SQLAlchemy sent to the database. AFAIU it re-enters your WSGI app entry point from the start, or at least that's what the previous repoze.tm2 middleware used to do. I don't know how it's all implemented in the new tween. There's definitely no scary magic SQL command capturing/replaying going on. > In any case, in > most cases you don't want to retry the transaction because it's caused > by a duplicate primary key, a wrong data type, a missing column or > table, etc -- not things that are temporary. So the right thing to do > is to rollback and display an error. Yes. The retry happens only when the very specific exception type is raised by the MVCC machinery of the database (ConflictError in ZODB; TransactionRollbackError in psycopg2). TransactionRollbackError in raw PostgreSQL terms is ERROR: could not serialize access due to concurrent update and the docs say "When an application receives this error message, it should abort the current transaction and retry the whole transaction from the beginning." [1] [1] http://www.postgresql.org/docs/8.4/static/transaction-iso.html. Marius Gedminas -- 99 little bugs in the code, 99 bugs in the code, fix one bug, compile it again... 101 little bugs in the code....
signature.asc
Description: Digital signature
