Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j!
I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? 2. How can I return the revision number from the TransactionEventHandler so I can use it in the caller (my service classes in this case)? 3. The caller should be able to pass data to the transaction, for now just the commit message. Of course I can temporarily store this in a node or attach it to the thread etc. but that just seems wrong. How can I do this right? Thanks and best regards, Georg On 27.04.2010 10:15, Mattias Persson wrote: > Hi everyone! > > I'm quite pleased to announce that the new event framework has been > committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework > got quite small and cosy. Here's a summary. > > *TransactionEventHandler* > can be registered at a GraphDatabaseService and will thereafter recieve > diffs of modifications made in each transaction before and after they are > committed. The transaction can still be modified in beforeCommit() and that > method can also throw an exception to prevent the transaction from > committing, causing a TransactionFailureException to be thrown from the code > which is committing the transaction. > > *KernelEventHandler* > can be registered at a GraphDatabaseService and will receive notifications > about when a shutdown is about to occur for the GraphhDatabaseService > instance. It will also receive notifications about "kernel panics" which is > a state which the kernel can come to from where it cannot continue without > needing to be restarted. An example of such an error would be a hard drive > breakdown or when no more space is left on the device the graph database is > running on. > > The next step is to write an "auto indexer" for the IndexService so that > that you won't have to do the manual indexService.index( node, key, value ) > anymore. Another thing would be to remove (deprecate) the > IndexService#shutdown() method as it no longer would be required. > > So it'd be great if you guys would try this out and tell us how it feels. > -- Georg M. Sorst Dipl. Inf. (FH) http://vergiss-blackjack.de Ignaz-Harrer-Str. 13 / Top 19 5020 Salzburg Österreich Tel: +43 (0)650 / 53 47 200 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
