openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: optimistic locking bug?
Date Mon, 04 Feb 2008 22:31:37 GMT
That was my conclusion too, but I thought that when I was looking at  
the SQL logging, that wasn't the case.

So, as a "best practice" for dealing with joined inheritance, have no  
cacading deletes for FKs in the db schema?

geir


On Feb 4, 2008, at 2:43 PM, Patrick Linskey wrote:

> It sounds like OpenJPA is issuing delete statements for both tables,
> but the cascade constraint from the first delete is causing the second
> row to be deleted before the second delete statement is evaluated. So,
> when the dependent row to be deleted is not found, OpenJPA assumes
> that this is because a different transaction deleted the record.
>
> -Patrick
>
> On Feb 3, 2008 3:02 PM, Geir Magnusson Jr. <geir@joost.com> wrote:
>> Single threaded code, 1 tx, my machine, no else one around...
>>
>> Code :
>>
>>
>>         /*
>>          * first _delete_ the ones we have
>>          */
>>         for (ShowInsertionPoint ip : list) {
>>             OMUtil.getEntityManager().remove(ip);
>>         }
>>
>>         OMUtil.getEntityManager().flush();
>>
>>
>> Exception in thread "main" <openjpa-1.0.1-r420667:592145 fatal store
>> error> org.apache.openjpa.persistence.OptimisticLockException:
>> Optimistic locking errors were detected when flushing to the data
>> store.  The following objects may have been concurrently modified in
>> another transaction: [com.joost.model.ShowInsertionPoint-4590,
>> com.joost.model.ShowInsertionPoint-4593]
>>
>> at
>> org 
>> .apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:
>> 2104)
>>        at  
>> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954)
>>        at  
>> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852)
>>        at  
>> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1623)
>>        at
>> org 
>> .apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:
>> 973)
>>        at
>> org
>> .apache
>> .openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java: 
>> 488)
>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>        at
>> sun
>> .reflect 
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>>        at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl 
>> .invoke(DelegatingMethodAccessorImpl.java:
>> 25)
>>        at java.lang.reflect.Method.invoke(Method.java:585)
>>        at org.springframework.orm.jpa.SharedEntityManagerCreator
>> $
>> SharedEntityManagerInvocationHandler
>> .invoke(SharedEntityManagerCreator.java:180)
>>        at $Proxy8.flush(Unknown Source)
>>        at
>> com
>> .joost
>> .md
>> .tools
>> .importexport
>> .fields
>> .show
>> .ShowInsertionPointsField 
>> .internalModify(ShowInsertionPointsField.java:
>> 209)
>>
>> Note, that I'm not explicitly using optimistic locking.
>>
>> A ShowInsertionPoint is a sub of InsertionPoint, using joined
>> inheritance.
>>
>> The tables :
>>
>> CREATE TABLE InsertionPoint (
>>   id int(11) unsigned NOT NULL auto_increment,
>>   itemType varchar(64) collate ascii_bin NOT NULL COMMENT 'The name
>> of the table that defines any subclass information.',
>>   insertionTime int(8) unsigned NOT NULL COMMENT 'in milliseconds',
>>   sourceCode int(4) unsigned NOT NULL default '1',
>>   quality float unsigned default NULL COMMENT 'Percentage (from 0.0
>> to 100.0) giving a (human) estimate of how well this insertion point
>> is placed wrt the content.',
>>   PRIMARY KEY  (id),
>>   KEY InsertionPoint_sourceCodeIndex (sourceCode),
>>   CONSTRAINT InsertionPoint_sourceCodeFK FOREIGN KEY (sourceCode)
>> REFERENCES InsertionPointSourceCode (`code`)
>> ) ENGINE=InnoDB AUTO_INCREMENT=35960 DEFAULT CHARSET=ascii
>> COLLATE=ascii_bin;
>>
>>
>> CREATE TABLE ShowInsertionPoint (
>>   id int(11) unsigned NOT NULL,
>>   showId int(11) unsigned NOT NULL,
>>   PRIMARY KEY  (id),
>>   KEY ShowInsertionPoint_showIdIndex (showId),
>>   CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
>> InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
>>   CONSTRAINT ShowInsertionPoint_showIdFK FOREIGN KEY (showId)
>> REFERENCES VideoShow (id) ON DELETE CASCADE ON UPDATE CASCADE
>> ) ENGINE=InnoDB DEFAULT CHARSET=ascii COLLATE=ascii_bin;
>>
>> The whole problem went away when I removed the constraint :
>>
>>   CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
>> InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
>>
>> from ShowInsertionPoint.
>>
>> Am I doing something wrong?  Or is there a bug in OpenJPA?
>>
>> tia
>>
>> geir
>>
>>
>>
>
>
>
> -- 
> Patrick Linskey
> 202 669 5907


Mime
View raw message