On Sun, Feb 1, 2009 at 8:43 PM, Emil Eifrem <e...@neotechnology.com> wrote:
> On Sun, Feb 1, 2009 at 6:47 PM, Johan Svensson <jo...@neotechnology.com> > wrote: > > A real implementation optimized of in-memory would require some work. > > Tobias, didn't you do some work on this for NeoMock and/or RemoteNeo? > Maybe something we could refactor out to an InMemoryNeoService at some > point. > I outlined the requirements for writing a InMemoryNeo based on RemoteNeo. What the most simple version would need is: 1. Set the caching policy to do as much of each transaction on the client as possible. - This would mean that the only requests being sent to the "server" before commit would be create node/relationship (to allocate an id), then every other change would be cached on the client and sent on commit, or dropped on rollback. 2. Implement a simple transport layer / "server" that stores all state in memory. (With the extra logic to allocate and be able to rollback node and relationship creations) In the first prototype of RemoteNeo, the cache configuration mentioned above is the default. This is not the case in the second prototype. The second prototype has swappable cache configurations, and the configuration needed for this setup is not implemented yet. The first prototype is in the repository as RemoteNeo (the second is called remote-neo), in my labs-directory. The first protype is has more testing behind it but does not support concurrent transactions. The second prototype is a moving target, but will be (closer to) the final version. I have a number of outstanding changes on the second prototype, but am not working actively on them at the moment since I am completely swamped with other committments. Cheers, -- Tobias Ivarsson <tobias.ivars...@neotechnology.com> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
