Re: Derby I/O issues during checkpointing

[Francois Orsini <fr...@gmail.com>]

In order for a thread to generate many outstanding I/O calls at a time, it
should *not* block on an I/O in the first place if it does not have to -
this is what you observed - Typically, we would want to be able to issue
Asynchronous I/O's so that a given thread at the low-level does not block
but rather is allowed to check for I/O completion at a later time as
appropriate, while producing additional I/O requests (i.e. read-ahead) -
Asynchronous I/O's in Java is not something you used to get out of the box
and people have implemented it via I/O worker threads (simulated Async
I/O's) or/and using JNI (calling into OS proprietary asynchronous I/O driver
on Unix FSs and Windows (NT)).

I think the approach you have made is good in terms of principles and
prototyping but I would think we would need to implement something more
sophisticated and having an implementation of worker threads simulating
asynchronous I/Os (whether we end-up using Java Asynchronous I/O in NIO or
not). I think we could even see additional performance gain.

Just my 0.02 cents...

--francois