Antonello,
Pass it in as a key/value pair in the constructor that takes a
configuration map:
Map params = new HashMap();
params.put( "use_memory_mapped_buffers", "false" );
NeoService neo = new EmbeddedNeo( "neo-db", params );
Hope that helps.
Regards,
-Johan
On Thu, Jul 2, 2009 at 5
i dnt knw whether its related to the topic or not
but am working on creating restful web service using jersey and then
planning to implement and consume these service through .NET WCF.(WSE seems
good option to me)
or using silverlight's webservice support.
please let me know what you guys think ab
Johan,
I checked out the latest sources from the SVN server of Neo and I
haven't found the entry point you told me about (EmbeddedNeo
constructor with "use_memory_mapped_buffers" parameter): can you
clarify me if this can be found in some branch of the project or if
isn't yet committed?
Thank you
Johan,
Thank you for the nice news (and sorry for the late response: I've
been on holidays and when came back I found loads of stuff to
accomplish): I will dig out soon and come back to you...
Cheers.
Antonello
On Mon, Jun 8, 2009 at 1:48 PM, Johan Svensson wrote:
> Antonello,
>
> Just thought
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 params ) constructor.
The code of plain buffer/direct buffer ports of pr
On Wed, May 6, 2009 at 02:05, Antonello Provenzano wrote:
> I will try to elaborate a plan of porting as soon as it will be
> possible, coming back to you if i will find anything that will be an
> obstacle to it. In the meanwhile, I thought that the name "neo4n"
> would be appropriate for the proj
Johan,
The plan of using "common" architectures is a great idea and will fix
the issues on porting and maintaining neo4j to .NET/Mono (please
remember that, as contributor to Mono, I'm attached more to this
framework than to Microsoft's one and I always seek for the full
compatibility with it).
I
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
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 i
See my comments inline:
On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano
wrote:
> Johan,
>
> I see. My knowledge of NIO is pretty limited indeed: since you're
> telling me it's re-designable with traditional java.io
> implementations, I see no particular issues on that side (also
> because, a
Johan,
I see. My knowledge of NIO is pretty limited indeed: since you're
telling me it's re-designable with traditional java.io
implementations, I see no particular issues on that side (also
because, as you described some of the core functionalities, many
features are already present in System.IO)
Antonello,
java.nio is used both for simplicity (code gets cleaner) and speed.
The transaction packages and nioneo packages can be rewritten to use
java.io but that would not perform very well. Basic file operations
needed would be:
o read/write into/from a buffer (byte array) from/to a file
o ch
Johan,
Thank you very much for the useful information and clarification: I
will dig out and come back on this later, when I will have clearer
view.
Concerning the "java.nio" issue: in .NET there's not a counter part
for the package. In fact, there's just the definition of the System.IO
namespace,
Hi Antonello,
Have a look at the neo-android component, dependency on
javax.transaction has been dropped there
(https://svn.neo4j.org/components/neo-android/trunk/) by just writing
empty interfaces for all the javax.transaction stuff needed.
javax.transaction / JTA and X/Open are just interfaces
Hi!
Thanks a lot for the information.
/anders
Antonello Provenzano skrev:
> Anders,
>
> IKVM doesn't support the javax.transactions package.
>
> In fact, the main difference pointed out by neo4j between java and
> .NET is the lack of support for X/Open XA resource management: this is
> possible
Anders,
IKVM doesn't support the javax.transactions package.
In fact, the main difference pointed out by neo4j between java and
.NET is the lack of support for X/Open XA resource management: this is
possible only by calling an "interop" OLEDB component, which is
non-native .NET, which should be i
Hi!
Have you tried using IKVM.NET?
http://www.ikvm.net/
/anders
Antonello Provenzano skrev:
> Emil,
>
> I'm a good expert on .NET architecture and technology, having
> contributed for years to the development of Mono and being a
> recognized developer and architect in this domain.
>
> Last week
Emil,
I'm a good expert on .NET architecture and technology, having
contributed for years to the development of Mono and being a
recognized developer and architect in this domain.
Last week I tried to implement a port version of neo4j for .NET,
applying the same concepts you implemented, not alwa
On Sun, May 3, 2009 at 03:55, Antonello Provenzano wrote:
> I've found that neo4j would be perfect for my scope: unfortunately, it
> is purely written in Java code and it's not portable to .NET, because
> of the massive differences between the two architectures.
>
> Can you tell me if is it there
19 matches
Mail list logo
