BTW, I tried to reproduce PK generator getting an incorrect PK range
on MySQL by emulating some load via JMeter. It never happens (at
least on a single VM instance). I wrote a test case that throws an
exception randomly on committing the user transaction. Still the
application was able to recover from failed transactions and carry on
processing other requests.
I am curious what Michael finds in his tests.
Anyways, I went ahead and added an explicit commit to the PK
generator (that code, although I couldn't make it fail, still looked
suspect) and posted new jars here:
http://dev.objectstyle.org/~andrus/cayenne-07132006/
Christian, I would appreciate if you could try this in your
application and see if you still get those errors.
Andrus
On Jul 13, 2006, at 11:53 AM, Andrus Adamchik wrote:
Cool, I'll wait for the results.
Andrus
On Jul 13, 2006, at 11:44 AM, Gentry, Michael ((Contractor)) wrote:
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:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 11:23 AM
To: [email protected]
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
