Re: Derby I/O issues during checkpointing

[Francois Orsini]

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