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:andru..bjectstyle.org]
> Sent: Thursday, July 13, 2006 11:23 AM
> To: cayenne-use..ncubator.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
>
This archive was generated by hypermail 2.0.0 : Thu Jul 13 2006 - 11:54:44 EDT