How does ETCD hold multi-transactions?

[PeterlitsZo]

Hello everyone,

I am reading the source code of ETCD. Now I am not sure how ETCD holds multi-transactions. It may:

• ETCD cannot hold multi-transactions.
• Or just I am wrong and miss something.

After reading the source code, I find when ETCD wants to create a transaction to write something, it:

1. It creates a storeTxnWrite as the write transactions object.

2. It makes the backend locked by the LockInsideApply method of BatchTx.

3. It modifies the treeIndex and Backend directly:

   // server/storage/mvcc/kvstore_txn.go (*storeTxnWrite).put
   
   tw.tx.UnsafeSeqPut(schema.Key, ibytes, d)
   tw.s.kvindex.Put(key, idxRev)
   tw.changes = append(tw.changes, kv)

4. After that, it unlocks the backend.

   // server/storage/mvcc/kvstore_txn.go (*storeTxnWrite).End
   
   // only update index if the txn modifies the mvcc state.
   if len(tw.changes) != 0 {
       // hold revMu lock to prevent new read txns from opening until writeback.
       tw.s.revMu.Lock()
       tw.s.currentRev++
   }
   tw.tx.Unlock()
   if len(tw.changes) != 0 {
       tw.s.revMu.Unlock()
   }
   tw.s.mu.RUnlock()

I am a totally new bird and I am confused that how the ETCD provides the interface of transactions - I cannot find where to roll back.

If it just uses a global lock - then everything makes sense. But how about the performance of this way?

Any kindly reply is welcome >_< Thanks a lot.

[serathius]

ETCD cannot hold multi-transactions

Etcd transaction is not like a database transaction with begin, commit or rollback commands. Txn is just a combination of operations and conditions send in one request that are executed atomically. Please check https://etcd.io/docs/v3.4/learning/api/#transaction for more.

I cannot find where to roll back.

No rollback. Txn request cannot be rollbacked.

[PeterlitsZo]

Thanks a lot. I find that the transactions of ETCD are different from other databases:

1. In ETCD, we only send one transaction request when we commit it.
2. But in other databases, we send many requests. For example, BEGIN, COMMIT, ROLLBACK, INSERT, SELECT, or something else.

So the pros and cons for ETCD:

• pros:
  • Easy to accomplish.
  • Do not worry about transaction conflicts - We can just use mutex to lock and unlock the backend.
• cons:
  • Cannot write program language to deal with domain logic.

But looks like the users of ETCD just want a simple transactions support. Am I right?

[ptabor]

Worth to notice that standard way to deal with multi-transaction use-case in etcd-like solutions is optimistic concurrency:

1. Your application reads a lot of objects. It remembers the revisions of this objects. It might happen in a lot of etcd transactions.
2. The application decides what mutation to perform based on the data... To guarantee that the objects have not changed in the meantime the transaction should contain preconditions whether the objects weren't mutated (lastUpdateRevision) since they were seen originally (in the point 1. ).

[PeterlitsZo]

Yes, of course. And that's why I am confused by ETCD because I just find it use mutex to deal with transactions.