Antonello, Just thought I'd mention that trunk now has support for non memory mapped buffers. When starting Neo4j just pass in:
use_memory_mapped_buffers=false as a parameter to the public EmbeddedNeo( String storeDir, Map<String,String> params ) constructor. The code of plain buffer/direct buffer ports of previously memory mapped ones are: org.neo4j.impl.nioneo.store.PlainPersistenceWindow org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer Regards, Johan On Tue, May 5, 2009 at 8:22 PM, Johan Svensson <jo...@neotechnology.com> wrote: > Next release of Neo4j (b9) will have an option not to use memory > mapped buffers but instead either use direct buffers or normal Java > buffers. A .NET port could replace the > org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different > implementation that does not use the MappedByteBuffer (b9 will soon > have such an implementation). > > In the transaction package any usage of MappedByteBuffer can be > replaced with a direct or normal buffer also (they all just append > data to some file). > > Hopefully I will get my test code of the new persistence windows into > trunk soon. Once that is done a .NET port could make use of that and > replace all other usages of memory mapped I/O with normal buffers. > > Regards, > Johan > > On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano > <antone...@deveel.com> wrote: >> I dug a bit the NIO package and the use done in neo4j: unfortunately >> there's not counter part for it on .NET nor the possibility to >> recreate [easily] classes to support it. In fact, you make a wide and >> important use of MappedByteBuffer on files: although implement the >> logics of a ByteBuffer class is not difficult (in .NET schema is the >> association of two classes: MemoryStream and >> BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears >> to be more complex, since access to portion of data in file which >> access must be coordinated with the memory, and this is not a simple >> issue. >> >> As of Java implementation, this is done natively and it's a complex >> operation to replicate the same functionality. >> >> Once this is solved, I see no further [major] obstacles to the port: >> avoiding the integration with the System.Transactions mechanism, the >> base of neo4j port would work in its core functionalities. >> >> Cheers. >> Antonello >> _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
