Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Neo4j
Home
+ new post
About this group
Join this group
Message from discussion Using TransactionEventHandler in HA Environment
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mattias Persson  
View profile  
 More options May 9 2012, 4:13 pm
From: Mattias Persson <matt...@neotechnology.com>
Date: Wed, 9 May 2012 22:13:13 +0200
Local: Wed, May 9 2012 4:13 pm
Subject: Re: [Neo4j] Using TransactionEventHandler in HA Environment
Print | View thread | Show original | Report this message | Find messages by this author

2012/5/9 Paul Jackson <paul_jack...@g1.com>

> OK, now I am confused.

> My understanding is that for a graph that was improperly shut down, the
> recovery process recovers data that was committed. It seems that for these
> transactions, the events should have already been fired in the process that
> wrote them, so if the system fired them during recovery, the events would
> be thrown a second time. Perhaps it depends upon the exact timing of when a
> record is considered committed. My guess would be that it occurs between
> the beforeCommit and AfterCommit events are raised. If this is correct, are
> these the two risks:

> 1) If the process dies between the time that beforeCommit is called and
> the transaction is committed, then the beforeCommit listeners receive a
> false event
> 2)  If the process dies between the time that the transaction is committed
> and afterCommit is called and, then the afterCommit is never raised

> I think you must be referring to a solution to the second risk - an ideal
> solution would fire the afterCommit events during recovery. Is this
> correct? In my scenario, it would be adequate to have some way of detecting
> that a recovery occurred, in which case I could run a consistency check
> during my initialization process, but the ideal solution would be... ideal.

Yup, you're absolutely correct. During recovery, transactions marked with
COMMIT record but not DONE record aren't guaranteed to have reached the
handlers with afterCommit and those could be sent to the handlers on
recovery, but that isn't happening currently, and would also require
handlers to be registered before recovery of course. Registration of
handlers shouldn't sit on GraphDatabaseService, but instead on
GraphDatabaseFactory<http://api.neo4j.org/current/org/neo4j/graphdb/factory/GraphDatabaseF...>imho.
This and/or notification about recovery performed and completed could
make the transaction event handling more solid.

> Thanks,
> -Paul

> On Wednesday, May 9, 2012 9:12:30 AM UTC-4, Mattias Persson wrote:

>> True, which of course is possible to add. I'd say the same problem exists
>> in the single instance scenario where a recovery is performed before the
>> constructor returns.

--
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google