[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434613 ]
Suresh Thalamati commented on DERBY-801:
----------------------------------------
Thanks for working on this issue, Anders. I really like your solution to solve
this issue. Patch is very good, I have only few minor comments/questions.
I am really sorry for not reviewing it sooner.
RAFContainerFactory.java
------------------------
Logic in this new class seems to be deciding whether to load RafContainer.java
or
the RafContainer4.java based on the JVM. I am not sure, if this logic is
necessary here. Did you consider using basic services to load the java classes
specific to a JVM ?
I think basic services has support to boot a specific factory implementation
based on the JVM using modules.properties. For example in the current
scenario, one can extend BaseDataFileFactory.java class to
implement newContainerObject(), which will return the RafContainer4( ..). add
the new class to modules.properties to boot only on versions >=jdk14.
In RafContainer4.java :
---------------------
1) I think following import is not needed.
+import java.io.*;
2) Is it really necessary to rewind() the buffers in readFull/writeFull ? From
what I understood,
there is a new ByteBuffer object being created on both read/write page
methods.
+ dstBuffer.rewind(); // Reset buffer position before we start read
and
+ srcBuffer.rewind(); // Reset buffer position before we start writing.
3) do we really need the following method ?
+ final protected FileChannel getChannel() {
+ return ourChannel;
+ }
4) I noticed, there is new encryption buffer created on every writePage() call,
if the database is encrypted. This may cause jvm peak memory usage increase,
when there is a checkpoint, if there are lot of dirty pages in the cache and
if garbage collection is not happening fast enough. I hope this does not
lead to out of memory errors!
We may need to implement some kind of scheme, that will help in reuse of
the encryption buffers.
5) I am ok with readPage() and writePage() routines in RafContainer4.java.
just curious , if you considered implementing new read/write..etc calls in
the RafContainer4.java using file channel and just wrapper methods in the
RafContainer.java using the existing random access file, instead of
overriding readPage()/writePage() ...etc.
6) Please file a JIRA to enhance StorageFactory interfaces to support NIO.
/suresh
> 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.1.1, 10.1.1.2,
> 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch,
> DERBY-801-v4.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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
