openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: optimistic locking bug?
Date Mon, 04 Feb 2008 19:43:18 GMT
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