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 >> > >
