I ran your test-case and to confirm, I see the ClosedByInterruptException during session.commit(), and the xadisk instance becomes unavailable after that.
A detailed summary...
When an application invokes the xadisk operations (not the remote xadisk invocation case, in which the application thread just does the network transfers for remote method calls), most of the work gets done in the application thread (in addition, there are a few xadisk worker threads running, doing their job asynchronously). XADisk uses NIO FileChannels heavily, which are interruptible. When an application thread calls an xadisk api which does any such FileChannel operation, and receives an interrupt, the channel would get closed and an exception will result. This channel may be for the transaction logs or any application data file etc. At this stage, the channel operation is incomplete (eg, an incomplete unknown amount of data was written), there is nothing much xadisk can do to continue working, as per its current design.
Altering the current implementation to cater to such interrupts (see interrupt, clean-up, and let only the current transaction go away leaving xadisk in-memory and persistent data in a consistent state) looks quite complex.
This should be a generic issue with any library which makes use of the interruptible io library like NIO. I tried finding out some workaround...
1. Disabling interrupt for a thread or for a FileChannel does not seem possible as per current Java. So, the application can run such application-threads by overriding the interrupt() method of the Thread class, where it can allow delaying the effective delivery of such interrupts. But note that this approach can interfere with some features of xadisk like deadlock handling, which uses thread interrupt internally (for transaction in wait state for lock). I am not sure how prevalent is this approach; just found it here and sharing: http://cs.oswego.edu/pipermail/concurrency-interest/2008-March/005064.html
2. Using the approach in 1. would involve frequent calls for enabling/disabling interrupts. As an alternative, the application can do away with the interrupt approach altogether and simply use a application level flag (instead of Thread.interrupt()) to communicate interrupts. Again, the application code would be filled-up with checks for this flag.
3. Use xadisk's remote method invocation. This would decouple the application-thread from the actual thread of the xadisk instance doing the job, but it would lead to slower performance due to socket based communication.
Please feel free to comment.
Thanks & Regards,