Hi, Thanks for all of the information. Of course the #1 solution to this problem is to ensure all transactions are closed before shutdown is called. I am trying to implement some kind of failsafe in the case that some unforeseen problem/bug causes transactions to remain open. What do you think of an optional parameter to shutdown() to signify "Do your best to rollback+finish any open transactions"? Or, could you provide a code example of how to close an Iterable of TransactionImpls using TransactionManager suspend and resume?
Thank you, Adam On Thu, Dec 10, 2009 at 4:46 AM, Johan Svensson <jo...@neotechnology.com>wrote: > Hi Adam, > > On Wed, Dec 9, 2009 at 4:37 PM, Adam Rabung <adamrab...@gmail.com> wrote: > > 1. This iterator will just prevent duplicates from being returned from > > the iterator? If there's a condition (bug in my code) that causes > > shutdown w/ open transactions, will the Lucene indexes continue to > > double until they're huge? > > > > Yes, currently the index may get duplicate entries for each non clean > shutdown. > > > 2. Would it be possible to detect this situation, and rebuild the > > indexes? I guess this is a losing cause if the app is regularly > > corrupting the data. > > > > Yes, it is possible to rebuild the index if everything that needs > re-index is reachable and stored in the graph. > > > 3. Could you allow me to close transacations from different threads? > > Yesterday, I wrote something that tracks tx opens and closes, and > > could iterate through all open transactions and call finish() on them. > > But TransactionImpl.finish seems to assume the calling thread is the > > creating thread, which is not the case here. > > > > I would recommend not to do this. It is better to make sure each > thread opening up a transaction manages that transaction and closes it > properly. You can however change thread for a transaction using the > TransactionManager's suspend() and resume() methods. > > > 4. Better yet, expose API for me to force-finish all open > > transactions? I'd rather have a botched transaction than a corrupt > > index. > > > > I do not think that is a good solution. What if some thread detected > that the running transaction has to be rolled back? If you > concurrently force commit from another thread then... Something that > may be possible to do is to force rollback any running transactions in > shutdown and wait for any transaction that has reached the > prepared/committing state to complete. > > > 5. Is the only condition for this open transactions + a Lucene > > shutdown (via shutdown() OR abrubt process termination)? In further > > testing, it seems I can't reproduce the problem w/ a clean or dirty > > shutdown if all transactions are closed. > > > > Correct, this will only happen after a crash/non clean shutdown > marking the logical log as dirty (meaning recovery will be run on next > startup replaying the logical log). > > > 6. I assume your iterator fix will make b11? What are the chances the > > root cause will be fixed in b11? Do you have a tentative release date > > for b11? > > > > We are planing to release in mid december/before christmas. A real fix > for this problem will not make it into that release so for now I would > suggest to properly close the transactions in the thread that opens > them. > > Regards, > -Johan > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
