Everything seems to be working now. My TransactionDelegate seemlessly
maintains the same connection. This is a very cool addition to 1.2, I
think.
On 2/6/06, Cris Daniluk <cris.danilu..mail.com> wrote:
> 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 : Thu Feb 09 2006 - 11:34:05 EST