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:andru..bjectstyle.org]
> Sent: Thursday, July 13, 2006 2:36 PM
> To: cayenne-use..ncubator.apache.org
> 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: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 - 14:56:55 EDT