2011/5/10 Rick Bullotta <rick.bullo...@thingworx.com> > Just a general question about the implementation of the Lucene Index > Framework for Neo4J. If I have an active transaction on thread "A" that is > doing a bunch of writes/deletes to Neo and to certain indexes, and I have > another transaction on thread "B" that is doing searches, but might also > remove an item from one of those indexes in the process (on another > transaction, of course), how are the concurrency issues associated with a > Lucene IndexWriter on the same index managed? I'm sure it is well above my > competency level to try to figure it out from the source (and the > implementation probably borders on wizardry), so I thought I'd ask first! >
Not far from the truth (about the wizardry part) :) No, but seriously. When a transaction is active and before the commit phase then all changes are made to objects holding transactional state and not to Lucene. So doing queries inside a transaction will merge the committed state (query lucene) and the transactional state into one coherent view, making it transparent that you're actually within a transaction. Then when the transaction commits it grabs a write lock on that data source representing lucene, writes all its transactional state to lucene (the IndexWriter) in an idempotent way and releases the lock. It doesn't actually force the IndexWriter to commit until the next rotation of the logical log or when shutting down. Crashes in between those points are guarded by the logical log and is used during the next startup of the graph database when it sees that a recovery is needed. > > Thanks! > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
