#60 Make Transaction obsolete after commit

closed-wont-fix
nobody
None
5
2005-03-30
2005-03-05
Allan Saddi
No

This patch makes Transaction.commit() mirror the actions taken in
Transaction.rollback(), namely expiring cached objects and marking
the Transaction obsolete.

I was motivated to make this change because I noticed my number
of database connections growing without bound and I realized why -
after calling trans.commit(), the underlying DBConnection was not
being released back into the pool. And because the transaction
wasn't being marked obsolete, it couldn't be reused by calling
.begin(). So in effect, that DBConnection was lost.

Discussion

  • Allan Saddi
    Allan Saddi
    2005-03-05

    Patch against 0.6.1

     
  • Oleg Broytman
    Oleg Broytman
    2005-03-29

    Logged In: YES
    user_id=4799

    You don't need to call .begin() after .commit(). Just
    continue your work and call .commit()....commit()....commit()...

     
  • Allan Saddi
    Allan Saddi
    2005-03-29

    Logged In: YES
    user_id=124421

    I guess I've misunderstood SQLObject's transaction semantics then. (I
    guess .commit() has an implied .begin(), while .rollback() does not?)

    I'll have to look at SQLObject deeper, since basically the effect I am
    looking for is to force all objects to re-fetch their values (when they are
    used) after .commit(). (It looks like .sync() may do this for an individual
    object?)

    It just seems wasteful to be forced to set _cacheValues to False when
    using transactions, since when using a transaction, you're guaranteed/
    supposed to have a consistent view of the database within the transaction
    block. Only when you use the object within a *new* transaction block (i.e.
    after .commit()) should its values be reloaded. (But is holding a reference
    to an object outside of a transaction block even correct behavior? The
    underlying row might get deleted outside of your transaction.)

    Anyhow, thanks for the clarification. I'll try to work around the issue. (And
    if I can't, I guess I'll use the patch locally and pray that the SQLObject
    codebase doesn't diverge so significantly that I can't use it anymore. ;)

     
  • Oleg Broytman
    Oleg Broytman
    2005-03-30

    Logged In: YES
    user_id=4799

    dbConn.commit()
    dbConn.cache.clear()

     
  • Oleg Broytman
    Oleg Broytman
    2005-03-30

    • status: open --> closed-wont-fix