Hi Eranda, Sorry about that, I should have tried it first not just guessed.
It looks like readPage and writePage in RAFContainer are overridden
by readPage and writePage in RAFContainer4, and it looks like we always
use RAFContainer4 for any JDK 1.4+ configuration. Mike or Knut Anders or somebody
else who's familiar with the store can probably confirm this for sure.
There is a class called BaseDataFileFactoryJ4 which arranges for this
overriding, though, and so I was able to re-point the store to use the
RAFContainer rather than the RAFContainer4 by simply making this change
— java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java(revision 958595)
+++ java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java(working copy)
@@ -42,6 +42,6 @@
- objects capable of exploiting the NIO API available in Java 1.4+
protected Cacheable newRAFContainer(BaseDataFileFactory factory)
- return new RAFContainer4(factory);
+ return new RAFContainer(factory);
Once I did this, I started to hit the readPage and writePage methods in RAFContainer.
Now, I'm not totally sure what the implications of this are. Since (I believe) Derby
no longer supports any JDK version prior to JDK 1.4 (I think Derby 10.2 was the
last version that supported JDK 1.3 – see
DERBY-1982), if RAFContainer is ONLY
used for JDK 1.3, then perhaps we should just remove RAFContainer, rather
than trying to fix it.
Does the problematic XSDG3 message arise in RAFContainer4 as well?
I did a quick search for FILE_CONTAINER_EXCEPTION in the code, and maybe
the message only occurs in RAFContainer, but it would be nice if somebody else
could confirm these analyses.
Basically, the question is: can we just remove RAFContainer (or, at least,
RAFContainer.readPage and RAFContainer.writePage), now that we no longer
support JDK 1.3?