On Feb 10, 2011, at 3:22 PM, Romy wrote: > Got it. > > My remaining question: if I stick with autocommit=False and eventually > use a transactional engine, how does wrapping the entire request > inside a transaction (say my request starts off with a DB query) > affect performance compared to using transactions inside only the > critical areas. Is there no benefit to excluding computational code > from transactions, as far as locking goes ?
DBAPI requires that connections are in a transaction at all times in any case unless you are using special flags specific to the database library that disable it. So generally its better to conform to that model by having one long transaction rather than lots of little ones, since they are always there regardless. note by "long transaction" we don't mean a transaction that's held open for two hours. we mean one that is long enough for a successive series of related activities. > > On Feb 10, 6:53 am, Michael Bayer <[email protected]> wrote: >>> I'm not sharing transactions, but why can I only have one transaction >>> per request ? >> >> sorry, more clear, don't share one transaction with multiple requests. >> few transactions per individual request is better too but not a requirement. > > -- > 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. > -- 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.
