2010/5/1 Georg M. Sorst <georgso...@gmx.de> > 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? > Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value. There's no "nice" way of locking a node other than setting/removing a property or creating/deleting relationships on it, so I'd say an ugly, but perfectly working way would be to do something like this:
nodeWithRevision.removeProperty( "a dummy property" ); int counter = (Integer) nodeWithRevision.getProperty( "revision" ); so that neo4j is forced to take a write-lock on that node before getting the "counter" property. A nicer way will be exposed soon to do this instead! 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)? > I'd say it'd be better if the service classes could read the revision from the node which has the revision directly, that way you'd always get the committed value. Maybe your handler could have a getRevision() method which reads the "revision" property from that revision node. > > 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? > I don't know what you mean by "pass data to the transaction" if it would not be to store something in the graph, f.ex. a property on a node. What exactly do you mean by that? > > 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 > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
