Forum: VoltDB Architecture

Post: ExecutionSite failed site handling question

ExecutionSite failed site handling question
Jun 23, 2011
Hello again and thank you for your earlier help.

I've been studying VoltDB's source code, and I noticed that you have a case in your handleSiteFault method where the transaction's initiator failed and the global initiation point is less less than the transaction ID. When is this possible? It seems to me that adding a new transaction to the transaction queue forces the global initiation point to be that value or greater.

Thanks for your help,

To answer my own
Jun 24, 2011
To answer my own question,

The global initiation point refers to the last safe txn id of the failed initiators for the site's partition, not the last seen txn id for the site's partition.

So a transaction might be pending but not safe before the fail.

Hi Sean, It's great to a have
Jun 25, 2011
Hi Sean,

It's great to a have an outside pair of eyes looking at this code.

Yes, the safe initiation point refers specifically to single partition txns. It's not that there is a specific initiator for a partition, but that a txn can't be executed unless it is fully replicated, and the replication is normally tracked by the initiator (which communicates the safe txn id for a given partition to each partition replica). If the initiator fails then the partitions don't know what txns from that failed initiator are fully replicated so they do the broadcast to say what they were told was fully replicated from the failed initiator. In that case the highest value reported as fully replicated by the initiator is fully replicated, txn ids higher then this may not have been received at every replica of the partition. We don't do the work to identify which ones are partially replicated and fully replicate them, we just drop them.

Multi-partitions txns have a coordinator on the node that initiated the txn, if the node leaves the cluster then the txn is rolled back (no new coordinator is elected). This sort of makes sense because there is no way to get the result of the multi-part txn back to the client with the initiator gone (same with single part txns). That is why it is only concerned with globally committed multi-partition txn ids.

Looking at this code again I have to ask, when two initiators fail concurrently, how can a single txn id represent the globally committed point for txns from both? I will have to discuss that with the group on Monday.

Sean, The issue with a single
Aug 9, 2011

The issue with a single txn id being used to represent the safe initiation point for multiple initiators has been fixed.

Thanks again for reviewing the code,