|
Actually, it is a race condition - in derby. Sometimes the two calls "makePersistentAll" cause derby to throw a SQLException, because the database timed out on a lock request (see below).
When an exception is thrown, the synchronization mechanism in the 4 tests does not work. This makes one of the two threads wait forever. This is the same problem as JIRA [java] ERROR 40XL1: A lock could not be obtained within the time requested [java] at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) [java] at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java) [java] at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java) [java] at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java) [java] at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(RowLocking3.java) [java] at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForWrite(OpenConglomerat e.java) [java] at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.fetch(GenericConglomera teController.java) [java] at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSetAutoincrementValue(DataDictionaryImpl.java ) [java] at org.apache.derby.impl.sql.execute.InsertResultSet.getSetAutoincrementValue(InsertResultSet.java) [java] at org.apache.derby.impl.sql.execute.BaseActivation.getSetAutoincrementValue(BaseActivation.java) [java] at org.apache.derby.exe.ac40348015x0104x675cxbca4xffffdab5f0bf0.e0(Unknown Source) [java] at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java) [java] at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java) [java] at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java) [java] at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java) [java] at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java) [java] at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) [java] at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java) [java] at org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:69) [java] at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:253) [java] at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1673) [java] at org.jpox.store.StoreManager.insert(StoreManager.java:634) [java] at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:2940) [java] at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:2913) [java] at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:959) [java] at org.jpox.AbstractPersistenceManager.makePersistentAll(AbstractPersistenceManager.java:1034) [java] at org.apache.jdo.tck.api.persistencemanager.cache.RefreshAllWithArraySideEffects$RefreshArrThreadT1.run(RefreshAllWithArraySideEffects.java:176) [java] at java.lang.Thread.run(Thread.java:595) Reopened to set the Fix Version/s field to JDO 2 beta.
|
||||||||||||||||||||||||||||||||||||||||||||||||||
However, the problem does not show up always. I could not find a deterministic way of reproducing it. If it shows up, then then the tests hang.
All tests execute 2 concurrent threads. Each thread performs a single transaction making one or more objects persistent. If the pm.makePersistent calls are prevented from executing in parallel then I can not reproduce the problem any more.