The basic strategy to refresh the primary key cache in MySQL is:
* lock table
* select next key values from auto_pk_support
* update auto_pk_support with a new next key (20 keys by default)
* unlock table
I was just looking at the MySQL docs for LOCK TABLES and it appears to
work differently
Looks like Cayenne interpreted C: path as a URL. Haven't looked at
the code, don't know why.
Andrus
On Jul 13, 2006, at 8:16 AM, Kevin Menard wrote:
So, I've been following the directions from
http://objectstyle.org/confluence/display/CAY/Cayenne+Maven but
have been
unable to get things
Is the PK cache per VM or per DataNode? I was thinking per DataNode
(obviously within the same VM, of course).
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
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
On 7/12/06, Andrus Adamchik [EMAIL PROTECTED] wrote:
Yes, there are a few ways of doing this. The cleanest one is this:
object.getObjectId().getReplacementIdMap().put(Treatment.BLA_BLA_PK,
UUID.randomUUID());
Thanks! Works great AFAICT.
Note that I had to remove the pk ObjAttribute as it is
On 7/12/06, Gentry, Michael (Contractor) [EMAIL PROTECTED] wrote:
You could override setPersistenceState() in your Treatment class:
public void setPersistenceState(int state)
{
super.setPersistenceState(state);
// If object was just created, set PK
if (state == PersistenceState.NEW)
On Jul 13, 2006, at 12:32 PM, Øyvind Harboe wrote:
On 7/12/06, Gentry, Michael (Contractor)
[EMAIL PROTECTED] wrote:
You could override setPersistenceState() in your Treatment class:
public void setPersistenceState(int state)
{
super.setPersistenceState(state);
// If object was just
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
Hi,
This might be a really random suggestion, but couldn't you use the
following strategy, even with autocommit=true?
public long getNextKey() {
boolean conflict = true;
while (conflict) {
key = SELECT current_key_value from auto_pk_table
next_key = key + increment;
UPDATE
Yes, the drawback is if you keep getting conflicts (which hopefully
would be minimal).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 4:54 PM
To: cayenne-user@incubator.apache.org
Subject: Re: Duplicate Key Problem
Hi,
This might
Am 13.07.2006 um 20:35 schrieb Andrus Adamchik:
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
11 matches
Mail list logo