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. <[EMAIL PROTECTED]> 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
