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? =)
Not sure when I made such a generic statement about storage factory
parallel access support, sorry if I had confused you. One thing I
wanted to work is if some one replaces the storage factory with
another implementation, new readPage/WritePage you added gets executed
instead of the old ones that allowed only single read/write of a
container file at a time.
I think we both are talking the same thing , As you say all that might
be needed is to add getChannel() method to the StorageRandomAccessFile
Interface and use it it in the RafContainer4.java instead of checking
for fileData is an instanceof java.io.RandomAccessFile.
Thanks
-suresh
