2009/6/25 Symeon (Akis) Papadopoulos <papa...@iti.gr>: > [My apologies for insisting on this issue.] >> There's (at least) two solutions to this problem. One is that, as you >> suggest, to have the iterator wrap its methods in transactions in >> addition to the code that returns the iterator (look at >> org.neo4j.util.TxIterator in neo-utils component). This solution can >> be tedious and perhaps not the most optimized. >> > After having a look at the source of the TxIterator, it appears as a > straightforward solution to my problem. > However, since the TxIterator opens and finishes a new transaction each > time any of the Iterator methods (hasNext(), next(), remove()) are > invoked, it appears that this will incur a significant penalty in > processes that go through the whole set of a graph's nodes in one go > (i.e. the TxIterator.hasNext() and TxIterator.next() methods are > successively invoked for each one of the graph's nodes). Do you know how > much this performance penalty could be? Alternatively, would it be safe > to have a transaction begin and finish every N (e.g. 10,000) calls to > the Iterator methods? If your transactions only performs read operations then the penalty isn't that much, however there's a slight overhead as you pointed out. For information on exactly how big this penalty would be I'll have to let others answer that... maybe Johan (if you read this)?
And sure you can do it like that (iterations of a couple of thousands at a time), it's seems like a good solution. There really should be an implementation of a tx-iterator in neo-utils that does just that. > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Neo Technology, www.neotechnology.com _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
