One can assume jdk 1.4 or higher in the trunk, it was agreed to
deprecate jdk1.3 starting with then next release (likely to be
called 10.3). Of course, do not backport any such change to 10.2
or before.
Anders Morken (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken resolved DERBY-801.
---------------------------------
Resolution: Fixed
OK, I'm marking this one as resolved, then. I've logged DERBY-2086 to remind us
to look into some kind of resource pooling mechanism for encryption buffers and
similar. I guess this isn't the only place where a pooling mechanism could be
useful, so I intentionally worded it in a generic fashion.
Regarding enhancing the StorageFactory interfaces to support general parallel
access, I'm not sure I understand Suresh's intention completely. Implementing
support for concurrent IO is specific to the different container types - and it
may not even be feasible for compressed containers that require on
decompression for seeks. Suresh, maybe you could explain it in a new Jira
issue? ;-)
As I considered earlier, we could enhance the StorageRandomAccessFile interface
to add getChannel() support, but even that would apply only to random access
files backed by real files that do support getChannel - and we'd have to throw
in some JVM-dependent trickery as well, since getChannel() in RandomAccessFile
only exists in Java 1.4+. (What's the timeframe on deprecating 1.3 support? I
guess it could be a while? =)
Anyway, thanks to everyone who helped me on this one. =)
Allow parallel access to data files.
------------------------------------
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Issue Type: Improvement
Components: Performance, Store
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Assigned To: Anders Morken
Fix For: 10.3.0.0
Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch,
DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch,
NIO-RAFContainer-v1.patch
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
