Hi Mattias,
thanks for your replies, finally getting back myself. Some
clarifications about questions 2 and 3, getting data in and out of the
transaction: What I am looking for is a way to do something like this:
int revision = transaction.finish(commitMessage, userId);
I've actually got this working by using a TransactionWrapper which
intercepts these calls and puts the data in a global Thread map. The
commit message and user id are then read out from the map by the
transaction event handler. This works fine, but passing around the data
in a global data structure just has an awful code smell.
While another way would be to have the service layer read out the
current revision and write the commit message itself etc. this smells
just as bad IMHO with duplicated code and an unclear calling chain.
So what I am looking for is a way to pass the data to the transaction as
explained above, or maybe also something like:
transaction.setAttribute("message", "my commit message");
tx.finish();
int revision = transaction.getAttribute("revision");
Now I see my first snippet is quite specific to implementing a
versioning system, but the later might be useful for other cases too. Is
there any way to do this or is anything planned?
Now that I've actually wrote about it my solution doesn't sound so bad
really :)
Best regards,
Georg
On 03.05.2010 17:03, Mattias Persson wrote:
> 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
>>
>
>
>
--
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
