cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gentry, Michael \(Contractor\)" <michael_gen...@fanniemae.com>
Subject RE: Duplicate Key Problem
Date Thu, 13 Jul 2006 18:51:49 GMT
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:andrus@objectstyle.org] 
Sent: Thursday, July 13, 2006 2:36 PM
To: cayenne-user@incubator.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:andrus@objectstyle.org]
>> 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
>>
>
>


Mime
View raw message