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 - 10:59:09 EST