Derby "ERROR 40XL1" in multithreaded test "RefreshAllNoParameterSideEffects"

• Key: JDO-324
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Michelle Caisse
• Reporter: Jörg von Frantzius
• Component/s: tck2
• Affects Version/s: JDO 2 rc1
• Fix Version/s: JDO 2 maintenance release 1

Description

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?

Comments

[Craig Russell]

I looked at the test, and it appears that the test is not correct. It is too complex for what it's testing, and doesn't even test what the assertion says.

For now, I propose adding the three test cases to the exclude list and fix this later.

[Michael Bouschen]

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.

[Michelle Caisse]

The attached file is a rewrite of the test per Michael's specification. Please review.

[Craig Russell]

Looks good. Just a couple of comments.

1. The failOnError should be outside the try...finally block, to make sure you see the error messages.

2. The indentation of " if (pntVerify.getX() != 33 " block is off.

3. I think you need to verify the values when doRefresh is false. You might not catch an exception but commit the change. I'd put the retrieval of the value outside the if(doRefresh) and check the values:

if (doRefresh) {
pntVerify == 33, 33
} else {
pntVerify == 22, 22
}

[Michelle Caisse]

How's this?

[Craig Russell]

Looks good.

[Michelle Caisse]

Checked in fix with revision: 465971