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/
