Issue Details (XML | Word | Printable)

Key: JDO-59
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Michael Watzek
Reporter: Michelle Caisse
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
JDO

tests hang with org.jpox.autoStartMechanism=None

Created: 08/Jun/05 06:54 AM   Updated: 23/Apr/06 02:30 AM
Return to search
Component/s: tck2
Affects Version/s: None
Fix Version/s: JDO 2 beta

Time Tracking:
Not Specified

Resolution Date: 23/Apr/06 02:30 AM


 Description  « Hide
The following tests hang with org.jpox.autoStartMechanism=None

org.apache.jdo.tck.api.persistencemanager.cache.RefreshAllNoParameterSideEffects
org.apache.jdo.tck.api.persistencemanager.cache.RefreshAllWithArraySideEffects
org.apache.jdo.tck.api.persistencemanager.cache.RefreshAllWithCollectionSideEffects
org.apache.jdo.tck.api.persistencemanager.cache.RefreshSideEffects

They are currently in test/conf/exclude.list .

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Michael Watzek added a comment - 14/Jun/05 07:05 PM
I can reproduce the problem using datastore identity - regardless of the setting org.jpox.autoStartMechanism. I cannot reproduce it using application identity.

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.

Michael Watzek added a comment - 14/Jun/05 07:07 PM
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 JDO-13.

    [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)

Michael Watzek added a comment - 14/Jun/05 07:08 PM
The same fix as JDO-13.

Michael Bouschen added a comment - 23/Apr/06 02:19 AM
Reopened to set the Fix Version/s field to JDO 2 beta.