The in-memory storage back end doesn't work on Windows

• Key: DERBY-4125
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Critical
• Assignee: Kristian Waagan
• Reporter: Kristian Waagan
• Component/s: Store
• Affects Version/s: 10.6.0.0
• Fix Version/s: 10.5.1.1, 10.6.0.0

Description

Bug reported by Knut Magne Solem, see DERBY-646.

Using the in-memory storage back end fails on Windows (i.e. connect 'jdbc:derby:memory:MyDbTest;create=true'; from ij):
ERROR XJ001: Java exception: 'ASSERT FAILED serviceName = memory:C:\Documents and Settings\user\workspace\derby\MyDbTest;storageFactory.getCanonicalName() = C:\Documents and Settings\user\workspace\derby\MyDbTest: org.apache.derby.shared.common.sanity.AssertFailure'.

With an insane build, the error messages will look like this:
ERROR XJ041: Failed to create database 'memory:myDB', see the next exception for details.
ERROR XBM01: Startup failed due to an exception. See next exception for details.
ERROR XSTB2: Cannot log transaction changes, maybe trying to write to a read only database.

The error occurs during boot, which means Windows users are unable to use the in-memory back end at all.

Comments

[Kristian Waagan]

Patch 1a fixes the bug.
It uses java.io.File to do most of the path handling. This should be far more portable than the old, broken approach.
The issue causing the problem reported, was detecting if a path was absolute or not. I also made some other changes, so that the paths stored in the data store are normalized paths.

I have tested it on Windows XP and OpenSolaris.
Patch ready for review.

[Kristian Waagan]

Committed patch 1a to trunk with revision 759176.
I'll wait a few days before I backport to 10.5. This fix needs to go in to allow Windows users to test the in-memory back end.

[Kristian Waagan]

Backported patch 1a to the 10.5 branch with revision 760387.

No more work is planned for this issue, unless additional problems are reported.