Besides Cayenne normally uses connection pool, so once the pool is
loaded, the connections are reused for the lifetime of the app. There
is something interesting going on there...
Andrus
On Jul 13, 2006, at 2:51 PM, Gentry, Michael ((Contractor)) wrote:
I've tried many times so far and haven't been able to get duplicate
keys
across two applications (different VMs in this case). This comment
from
Christian sounded a bit extreme to me, though:
"The db has collected 3893813 connection attempts and 534 aborted
clients
since we restarted the db two days ago."
A normal Cayenne application would generate very few connection
attempts. 3.8 million in 2 days? That's 2700 connections/minute.
That
is a LOT. (My Tapestry-based application probably does 1-2
connections/database per week, depending on load/etc.) I wonder if
MySQL could be stuttering or having a few issues under that kind of
load?
/dev/mrg
-----Original Message-----
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 2:36 PM
To: [email protected]
Subject: Re: Duplicate Key Problem
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
