On Mar 1, 2:29 am, Michael Bayer <[email protected]> wrote:
> On Mar 1, 2011, at 1:42 AM, Romy wrote:
>
> > Getting some conflicting advice on autocommit and wrapping the request
> > in a try/except block on the Tornado mailing list, was wondering what
> > your thoughts are on the issues brought up in the following message
> > and its replies:
>
> >http://groups.google.com/group/python-tornado/msg/d06a7e244fc9fe29
>
> I have never worked with async servers so I don't have much wisdom on the 
> best usage patterns with relational databases, I think the suggestion to wrap 
> individual queries in a try/except defeats the one of the purposes of using a 
> transactional, relational database.   It shouldn't be an exotic need to treat 
> several SQL statements in succession as part of a single logical series of 
> operations, that series of operations linked to the scope of a single HTTP 
> request.   It's of course optional, though I'd like to think I emit four 
> INSERT statements in a request, then the fifth one fails, I can roll the 
> whole thing back.  Similarly that I can emit SELECT statements that will 
> share the same isolated environment of one transaction, won't release row 
> locks before I'm done, etc.

Don't let the async nature throw you -- my code is 99% synchronous and
in the async calls I can easily handle the database behavior manually.

WRT your 5 insert example, what's wrong w/ explicitly marking those
single logical units inside a BEGIN ... COMMIT while running
autocommit ? Same goes for wrapping SELECTs and anything else you
might need. I've found there to be nothing awkward about this approach
when I had autocommit on.

How do you feel about the effects on locking as it pertains to
elongated transactions ? It looks like the more strict the isolation
mode, the more this hurts concurrency. Even at the repeatable-read
defaults this could lead to SELECTs issuing write-locks for as long as
they're in a transaction.

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" 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/sqlalchemy?hl=en.

Reply via email to