Mike-
>From what I read: the multiple attempts are to deal with issues where
you lose the database connection through an API. I think by default
it tries 3 times, then fails for real.
The exact error didn't happen on a get(), it happens like this:
useraccount= add() or get()
db.flush()
print useraccount.id # yay
transaction.commit()
print useraccount.id # raises
sqlalchemy.orm.exc.DetachedInstanceError
So you get """DetachedInstanceError: Instance <Useraccount at
0x103f9f610> is not bound to a Session; attribute refresh operation
cannot proceed """ on doing anything to the object.
I've ultimately oped against pyramid_tm
one of key points was that I have a handful of logic blocks that
interact with the facebook api. their api can be a bit unstable, and
can lag a bit too. on many of my webapp operations, I could end up
with a transaction block locking key tables for a few seconds -- which
really hurts concurrency. i really need to explicitly commit within
the transaction -- not a savepoint -- save the data I know is good,
and gracefully handle fixups in the background.
Marius-
For years, I've had code that does this:
try:
do stuff
database.commit()
email.send()
except:
so I'm fine with the paradigm you're suggesting ;)
On Feb 15, 1:26 pm, Mike Orr <sluggos...@gmail.com> 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/GVFj...
>
> >> ( 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/int...
> >> ) , 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. 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. 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.
>
> As for transaction.commit() recreating the session, that's not
> necessarily a problem. It just means that if you re-get the same
> records, they'll be loaded from the database rather than being fetched
> from the session memory. But if you're re-getting the same records,
> why didn't you keep a reference to them?
>
> It
>
> > requires certain care in your app code (e.g. not sending emails directly
> > from your app but instead using something like repoze.sendmail that hook
> > with the transaction and perform the sending only on successful
> > commits).
>
> > Marius Gedminas
> > --
> > Theory is when you know something, but it doesn't work. Practice is when
> > something works, but you don't know why. Programmers combine theory and
> > practice: Nothing works and they don't know why.
>
> --
> Mike Orr <sluggos...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
