ERROR 23503: INSERT on table 'COLLECTION_OF_SIMPLE_CLASS3' caused a violation of foreign key constraint

• Key: JDO-143
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Michelle Caisse
• Reporter: Michelle Caisse
• Component/s: tck2
• Fix Version/s: JDO 2 beta

Description

    [java] 1) test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)javax.jdo.JDODataStoreException: Add request failed : INSERT INTO applicationidentity0.COLLECTION_OF_SIMPLE_CLASS3 (IDENTIFIER,ALLOW_DUPLICATES,SIMPCLSREF) VALUES (?,?,?)
    [java] at org.jpox.store.rdbms.scostore.NormalSetStore.add(NormalSetStore.java:672)
    [java] at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:489)
    [java] at org.jpox.store.mapping.container.CollectionMapping.postUpdate(CollectionMapping.java:279)
    [java] at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
    [java] at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1838)
    [java] at org.jpox.store.StoreManager.update(StoreManager.java:782)
    [java] at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4298)
    [java] at org.jpox.state.StateManagerImpl.runReachability(StateManagerImpl.java:3102)
    [java] at org.jpox.AbstractPersistenceManager.preCommit(AbstractPersistenceManager.java:3049)
    [java] at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:419)
    [java] at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
    [java] at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
    [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:115)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:93)
    [java] NestedThrowablesStackTrace:
    [java] ERROR 23503: INSERT on table 'COLLECTION_OF_SIMPLE_CLASS3' caused a violation of foreign key constraint SQL050921005031671' for key (1127341751473). The statement has been rolled back.
    [java] at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
    [java] at org.apache.derby.impl.sql.execute.ForeignKeyRIChecker.doCheck(Unknown Source)
    [java] at org.apache.derby.impl.sql.execute.GenericRIChecker.doCheck(Unknown Source)
    [java] at org.apache.derby.impl.sql.execute.RISetChecker.doFKCheck(Unknown Source)
    [java] at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source)
    [java] at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
    [java] at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
    [java] at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
    [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
    [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
    [java] at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:105)
    [java] at org.jpox.store.rdbms.scostore.BaseContainerStore.executeUpdate(BaseContainerStore.java:97)
    [java] at org.jpox.store.rdbms.scostore.NormalSetStore.add(NormalSetStore.java:654)
    [java] at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:489)
    [java] at org.jpox.store.mapping.container.CollectionMapping.postUpdate(CollectionMapping.java:279)
    [java] at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
    [java] at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1838)
    [java] at org.jpox.store.StoreManager.update(StoreManager.java:782)
    [java] at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4298)
    [java] at org.jpox.state.StateManagerImpl.runReachability(StateManagerImpl.java:3102)
    [java] at org.jpox.AbstractPersistenceManager.preCommit(AbstractPersistenceManager.java:3049)
    [java] at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:419)
    [java] at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
    [java] at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
    [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:115)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:93)

Possibly due to a misordering of inserts required for this operation?

Comments

[Michelle Caisse]

This error occurs only with application identity. With datastore identity, the test runs but fails. See JDO-144.

[Andy Jefferson]

Hard to follow the TCK test in terms of the data in each of the collections so I'll post my findings here so someone who understands the data that is trying to be persisted can comment. There are 2 fields of note in the CollectionCollections class : "CollectionOfSimpleClass42", and "CollectionOfSimpleClass3".
The former has embedded elements and the latter is unembedded, just having a FK to the SimpleClass table. Debugging suggests that both of these collections contains the same element(s). It's being encountered as part of the CollectionOfSimpleClass42 field and has a StateManager assigned (as an embedded object) and is persisted (into the join table). When JPOX gets around to persisting the CollectionOfSimpleClass3 field JPOX finds the already persistent SimpleClass element and so think it's ok to insert the join table row - hence the FK fails.

Do these collections contain the same elements ? If so what are you expecting a JDO impl to do in this situation ? Make a copy of the PC object and persist that ? If so, please provide a reference to the section of the JDO2 spec defining such behaviour.

[Craig Russell]

Hi Andy,

Thanks for this analysis, Andy.

This situation is not covered by the specification. So it's a test bug. Even if it were covered by the specification, I'd expect it to say that an exception should be thrown.

The test case should not assign the same instance to both an embedded field and a non-embedded field. So the bug should be reassigned to Michelle. And we should look at all of the other collection test cases to make sure that this same situation isn't in the other tests.

The spec does say it's ok to assign the same embedded instance to multiple fields, but as far as I know there's no test case for this.

You might consider adding a JPOX check to make sure that when persisting a PC instance that is known to be embedded, then only embedded uses are permitted. Similarly, persisting a PC instance that is known to be non-embedded, then only non-embedded uses are permitted. Its the case of a PC instance being used as both embedded and non-embedded that's problematic, and if possible it would be nice to throw a different exception.

The collections tests in the fieldtypes package all obtain a single instance of a Vector for each datatype under test. So, there is only one Vector of SimpleClass instance that is reused for each CollectionOfSimpleClass element in CollectionCollections.

[Michelle Caisse]

Currently values for Collections of Collection types are obtained as a Vector with one value for each different datatype represented in the fields of the class. Each field of the same data type is assigned the same instance from this Vector. org.apache.jdo.tck.models.fieldtypes.FirstSetOfTestValuesForCollection.java and ...SecondSetOfTestValuesForCollection.java each contain a vector field for each data type.

I propose removing these two classes from the repository, adding a static method to org.apache.jdo.tck.models.fieldtypes.TestUtil.java that takes the field data type and an integer specifying whether this is the first or second value as arguments, and returns a new Vector of new object instances on each invocation. TestCollectionCollections.java must also be modified to use the static method to get test values. Its checkValues() method must be modified to use a CollectionCollection type as the standard rather than using a FirstSetOfTestValuesForCollection or SecondSetOfTestValuesForCollection type as the standard.

If we decide to go ahead with this change, all the other Test*Collection.java files will have to be changed as described. I would also address issues JDO-145 and JDO151- in the same checkin, because they involve the same set of files.

[Michelle Caisse]

The attached patch shows the proposed changes for TestCollectionCollections.java and TestUtil.java only. Changes still need to be made to the other Test*Collections.java files.

[Craig Russell]

Hi Michelle,

Your proposed patch looks good. The use of a new Vector for each request makes sense and avoids the issue of assigning the same persistent instance to both embedded and non-embedded collections.

[Michelle Caisse]

test\java\org\apache\jdo\tck\models\fieldtypes\FirstSetOfTestValuesForCollection.java

[Michael Bouschen]

Reopened to set the Fix Version/s field to JDO 2 beta.