Re: queries in TransactionDelegate spawn new connection

From: Cris Daniluk (cris.danilu..mail.com)
Date: Mon Feb 06 2006 - 15:29:02 EST

  • Next message: Cris Daniluk: "SQLTemplate / inExp"

    Super cool! I will give it a shot and see how it works :)

    On 2/6/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
    > Just checked in a fix for that problem (CAY-439). Finally internal
    > Transactions start to resemble real transactions ;-) Per my unit
    > tests you can even wrap multiple DataContexts in manual internal
    > transactions.
    >
    > Andrus
    >
    >
    > On Feb 6, 2006, at 10:59 AM, Andrus Adamchik wrote:
    >
    > > Good point. While Cayenne transaction ensures consistent commit/
    > > rollback of multiple connections involved in the same transaction,
    > > it doesn't deal with isolation levels or DataSource management (I
    > > am surprised that it worked before?).
    > >
    > > The API was designed to rely on external transaction management in
    > > cases when Cayenne and non-Cayenne users access the same
    > > DataSource. But this overlooks the fact that there can be a second
    > > Cayenne process accessing DB in the same transaction via the delegate.
    > >
    > > With the new thread-bound Transaction approach, I think we can
    > > easily fix this problem and enable correct delegate functioning for
    > > internal transactions as well. I guess we can patch the DataNode
    > > and Transaction to obtain new connections from the thread
    > > Transaction instance, with the same Connection being handed
    > > repeatedly in the same thread.
    > >
    > > Andrus
    > >
    > >
    > > On Feb 6, 2006, at 9:51 AM, Cris Daniluk wrote:
    > >
    > >> I had previously asked about running stored procedures within the
    > >> same
    > >> transaction as other write operations and was advised to use a
    > >> TransactionDelegate:
    > >>
    > >> http://www.objectstyle.org/cayenne/lists/cayenne-user/
    > >> 2005/07/0132.html
    > >>
    > >> I'm fairly certain it wasn't doing this before, but in one of the
    > >> recent milestones, it started spawning a new connection for the
    > >> queries run within the willCommit() method.
    > >>
    > >> While a rollback triggered by my "inner" connection would trigger a
    > >> rollback in the "outside" connection, the locking is all screwed
    > >> up...
    > >> write locks are still held on tables needed by the stored procedure,
    > >> so it deadlocks now. I poked around some of the new Transaction
    > >> stuff,
    > >> but I can't seem to figure out how I might force a ProcedureQuery to
    > >> be appended to the same *database* transaction, not just Cayenne
    > >> transaction.
    > >>
    > >> Cris
    > >
    > >
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Feb 06 2006 - 15:29:04 EST