db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Bouschen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-324) Derby "ERROR 40XL1" in multithreaded test "RefreshAllNoParameterSideEffects"
Date Wed, 01 Mar 2006 20:30:51 GMT
    [ http://issues.apache.org/jira/browse/JDO-324?page=comments#action_12368352 ] 

Michael Bouschen commented on JDO-324:

I agree, the test is not correct.

I think we do not need multiple threads to test the assertion. Here is what I think the test
should do:
- Setup creates a new instance, commit the trsnaction and stores the oid in an instance variable.
- Create a pm, start an optimistic transaction and read the object with pm.getObjectById using
the stored oid.
- Create another pm, start a new transaction, read the same object, update it and commit the
second transaction.
- The first transaction calls pm.refresh for the object, updates it and commits the transaction.
The above should not result in an exception because the refresh call synchronizes the cache
with the current state of the datastore, so there is no parallel update.

> Derby "ERROR 40XL1" in multithreaded test "RefreshAllNoParameterSideEffects"
> ----------------------------------------------------------------------------
>          Key: JDO-324
>          URL: http://issues.apache.org/jira/browse/JDO-324
>      Project: JDO
>         Type: Bug
>   Components: tck20
>     Versions: JDO 2 rc1
>     Reporter: Jörg von Frantzius
>  Attachments: derby-dsid-pm-junit.txt
> When using latest JPOX nightly (01-Mar-2006 04:21), I get a "ERROR 40XL1: A lock could
not be obtained within the time requested" Derby error (see next attachment for log file).
This happens while running RefreshAllNoParameterSideEffects, which is multithreaded, and it
happens for both threads.
> This is with Windows XP SP2 and JDK 1.4.2_09 on a dual core machine. Maybe the fact that
it is dual core leads to different timing than single core?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message