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