Hi Thomas, I spend three evenings with your code, very readable and nice. As result I wrote two new implementations of FileObject .
FileObjectDiskChannel.java - * uses NIO FileChannel instead of random access file. There are no catches, so should be safe to use. FileObjectDiskMapped - * uses NIO MappedByteBuffer. * This is 'first shot' implementation and should be used carefully. * Buffer is remaped every time file size changes (so bad performance in this case). * Hack with System.gc() to force old buffer to unmap, As result file can be safely closed and deleted (even on Windows). * not tryed MappedByteBuffer.load() yet (can improve or degrade performance for reading) * Can handle only files smaller then 2 GB (can be fixed) Both FileObjects are passing all unit test. I did not validate performance yet. I would be happy if you would take those patch for spin, run your performance tests and send me your thoughts. Also what is chance of integrating this to main branch? As optional engines with prefix on connection URL(jdbcChannel, jdbcMapped)? Regards, Jan Kotek On Tue, Mar 3, 2009 at 8:43 PM, Thomas Mueller <[email protected]> wrote: > > Hi, > >> is there any progress/plan for NIO based storage? I will play with H2 >> in this direction so I would like to know situation. > > No, currently there are no plans (at least not from my side). However > I plan to write a new storage engine that is based on blocks (2 KB or > 4 KB each). See PageStore and related classes. > > Regards, > Thomas > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
h2-nio.patch
Description: Binary data
