But, I think I get what you’re asking. Assuming your application never crashes, and you never lose your network connection to the Couchbase cluster, what specifically can you do to improve durability with Couchbase. Is that right?
Yes, My main issue is when I told my end user that transaction is completed, it must not lost, If they see history of transaction they can see completed transaction any time after my confirmation, no matter what happens, It must be durable after confirmation or no confirmation send to end user if we cannot ensure durability
I know that your example is idempotent, But I don’t get how it can help me, I know that Idempotency is the solution of my problem, I don’t get how exactly to implement it
See Multi-document transactions: ACID and Couchbase Part 2
My logic is more complex than what is in blog’s tutorial, let’s change States a bit
public enum TransactionStates
{
Initial = 0,
Pending = 1,
Committed = 2,
Done = 3,
Cancelling = 4,
Cancelled = 5,
Failing = 6,
Failed = 7
}
If transaction remains more than 15 minutes in processing we must go to failing
My concern is just done state, I want to create a mechanism that guaranteed we don’t go to the done state unless we can guarantee that it remains on done state or at failure it go to done again
My concern is I cannot create mechanism by Idempotency, all operations that change transaction States is idempotent
But my issue is 15 minutes timeout, and the rare case when the transaction is done
by primary node and processing
by secondary node , at failure if we restart with secondary node and repeat logic after a while everything is OK, but after 15 minutes , transaction is failing and failed not done , I have a confirmation the end-user that is not correct and there is no way for human reconciliation, so the payee lost the money
How to log it? In a simple file? My application is distributed too, Must I use central log system? Is really needed to log , It convert my app to more complex app