cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gentry, Michael \(Contractor\)" <michael_gen...@fanniemae.com>
Subject RE: Duplicate Key Problem
Date Thu, 13 Jul 2006 15:44:23 GMT
The quickest way to test that I can think of is to be stepping through
the PK generation code in the debugger and after you lock/select the
PKs, use "mysqladmin kill" to kill your connection before the
update/unlock.  You can then try to access the auto_pk_support table
from another app (or the mysql prompt) and see if it is still
locked/etc.  I might could use my CayenneExample (with a few tweaks) to
test this in a bit.

/dev/mrg


-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org] 
Sent: Thursday, July 13, 2006 11:23 AM
To: cayenne-user@incubator.apache.org
Subject: Re: Duplicate Key Problem



On Jul 13, 2006, at 10:57 AM, Gentry, Michael ((Contractor)) wrote:

> Is the PK cache per VM or per DataNode?  I was thinking per DataNode
> (obviously within the same VM, of course).

True, more accurately it is one per DataNode, and is shared by all  
DataContexts that sit on top of a given DataDomain.


> Another thing that could be tricky is that the MySQL JDBC connector
> (Connector/J) has an autoReconnect=true option, which would catch a
> disconnection before Cayenne could see it and reconnect.  Not sure at
> all what would happen to an in-progress transaction if that were the
> case.

Good point. But I am more concerned about runtime exceptions in the  
code that theoretically can cause a PK range to become invalid. One  
straightforward way to fix that is to apply the same approach we did  
for Sybase PK generator per CAY-588 (i.e. ensure that PK is generated  
outside of the main transaction. I guess that's what we'll have to  
do, but I want to have a way to reproduce the problem first, if only  
to know that our fix actually fixes it.

Andrus

Mime
View raw message