Golang client ReadTransact performs transaction commit.

[solganik]

Hi, in foundationdb documentation it says (and shown in example) that read transactiuons does not have to have a "commit". example

void readData(FDBDatabase *db)
{
    //  get value
    FDBTransaction *tr;
    checkError(fdb_database_create_transaction(db, &tr));
    char *key = "Test Key2";
    FDBFuture *getFuture = fdb_transaction_get(tr, key, (int)strlen(key), 0);
    waitAndCheckError(getFuture);
    
    fdb_bool_t valuePresent;
    const uint8_t *value;
    int valueLength;
    checkError(fdb_future_get_value(getFuture, &valuePresent, &value, &valueLength));

    printf("Got Value for %s: '%.*s'\n", key, valueLength, value);
    fdb_transaction_destroy(tr);
    fdb_future_destroy(getFuture);
}

However looking at golang client implementation:

func (d Database) ReadTransact(f func(ReadTransaction) (interface{}, error)) (interface{}, error) {
	tr, e := d.CreateTransaction()
	// Any error here is non-retryable
	if e != nil {
		return nil, e
	}

	wrapped := func() (ret interface{}, e error) {
		defer panicToError(&e)

		ret, e = f(tr)

		if e == nil {
			e = tr.Commit().Get()
		}

		return
	}

	return retryable(wrapped, tr.OnError)
}

Is this done intentionally ? or this is a bug in ReadTransact implementation ?

[gm42]

@alecgrieser or @johscheuer, maybe you know the answer to this question? :thinking:

[alecgrieser]

I don't think it's a bug, per se, as while read-only transactions don't need to be committed, the penalty for committing them is also low. (The client basically validated that the transaction is read only, and if so, it doesn't make a request to the server to commit it.) So, in many of the bindings, the "read" operation is actually implemented just by calling the "run" operation, but taking an operation that operates on a restricted view of the transaction to only read-only operations.

[gm42]

The client basically validated that the transaction is read only, and if so, it doesn't make a request to the server to commit it.

If no locks are involved on client side, it is indeed a no-op; thanks for the reply!