On Wed, Feb 15, 2012 at 09:05:01PM +0200, Marius Gedminas wrote: > 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.
[*] http://docs.pylonsproject.org/projects/pyramid_tm/en/latest/#retrying > > 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.... Marius Gedminas -- Anything can be made to work if you fiddle with it long enough.
signature.asc
Description: Digital signature
