I've apparently been overthinking this...
Since network transactions are idempotent, this much simpler system
should work even better:
1) Commit the network transaction
2) Commit the database transaction
3) ACK the packet instigating this update
4) Client receives ACK
If we crash any time before step 2 completes, then all that we are at
risk of repeating is the network transaction
If we crash after 2 completes but before step 4, the client will
continue to resend the packet.
If we see the packet after steps 1 and 2 are completed, then we will
realize that no updating of the database needs to be done - because the
database will reflect what had been done in step (2) before.
I don't know why this looked so hard to me before.
What did I miss?
On 08/16/2013 11:57 AM, Alan Robertson wrote:
> Hi,
>
> I had some additional thoughts about transactions - and a different
> (better?) way to handle the combined transactions...
>
> Here is a way to create the combined transaction without any additional
> persistence mechanism:
>
> Make each transaction into two:
> One that commits the database transaction and records the needed
> network transaction in Neo4j
> One that removes the needed network transaction created by the first
> step
>
> In the first transaction, you create a new node that holds the JSON for
> the network transaction
> and either put it in an index or relate it to a Transaction node
> (latter is probably faster).
>
> Then you commit the first transaction
>
> Then you execute the network transaction and create a new transaction
> that removes the NetTrans
> node and its relationship (or index entry), and ACKs the packet from the
> client.
>
> This would have the advantage that the database transaction wouldn't
> have to be idempotent - because it would never be repeated. Network
> transactions still needs to be idempotent (which they are). [An
> alternative is to figure out if the transaction has been committed when
> we restart - which should be possible].
>
> This method would also not require any additional persistence mechanisms.
>
> When you first start up, you look for any NetTrans nodes out there, and
> commits them. Now the database and the network are consistent.
>
> If you crash before the first transaction completes, then the client
> just keeps resending its data waiting for us to ACK it. When we come
> back up, we receive the packet, and carry out the actions that go with it.
>
> Thoughts? [I'm aware it has a performance penalty]
>
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
