New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go binding: do not commit read-only transactions #11366
base: main
Are you sure you want to change the base?
Conversation
d07c298
to
f40de3c
Compare
@johscheuer what do you think about starting to add a test suite for the Go binding? (in separate PRs) |
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No forms of testing were done as I cannot locate a test suite for the Go bindings; would be happy to contribute some in a separate PR.
There are tests, those are located here: https://github.com/apple/foundationdb/blob/main/bindings/go/src/fdb/fdb_test.go. Those tests require a running FDB cluster.
I understand that based on the docs it's not required to perform a commit. Have you observed any issues with doing the commit or any improvements by not committing? I'm trying to understand what is the benefit of this change and how you came across this.
Thanks! Is there any area which needs more coverage?
I came across this by reading the C API documentation; the benefit is at the very least to clarify whether this is necessary to do, or not. If not, it should not commit and possibly do it even better than I am proposing here e.g. not relying on GC for the transaction destruction. The performance improvement seems very small, I found it hard to measure in Go so far but I can try again. I would probably also want to measure the difference using a C program; by looking at how commits of R/O transactions are discarded in the fdbclient code, it makes sense that the benefit is small as there is little operations and memory reads involved (all on client side). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are tests, those are located here: https://github.com/apple/foundationdb/blob/main/bindings/go/src/fdb/fdb_test.go. Those tests require a running FDB cluster.
Thanks! Is there any area which needs more coverage?
I believe we are good. There are some tests for read-only transactions: https://github.com/apple/foundationdb/blob/main/bindings/go/src/fdb/fdb_test.go#L169-L220
I'm trying to understand what is the benefit of this change and how you came across this.
I came across this by reading the C API documentation; the benefit is at the very least to clarify whether this is necessary to do, or not. If not, it should not commit and possibly do it even better than I am proposing here e.g. not relying on GC for the transaction destruction.
I'll take another look when I'm back. I'm not against this change, was only curious behind the motivation :)
The performance improvement seems very small, I found it hard to measure in Go so far but I can try again. I would probably also want to measure the difference using a C program; by looking at how commits of R/O transactions are discarded in the fdbclient code, it makes sense that the benefit is small as there is little operations and memory reads involved (all on client side).
I think it's fine (until we have some benchmark tests in the bindings, which sounds like a good idea). Like I said I was mostly curious about the motivation of the change :)
Inquiries are very welcome in any case :) for example with this change one could uncover a bug somewhere else, due to side effects. |
I have added another commit for the second approach, destroying the transaction explicitly without relying on on GC. It would make a difference if the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux CentOS 7
|
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Seems like the tests are not passing:
|
bindings/go/src/fdb/database.go
Outdated
return Transaction{}, err | ||
} | ||
|
||
runtime.SetFinalizer(outt.transaction, outt.transaction.destroy) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this doesn't work as expected:
fatal error: runtime.SetFinalizer: cannot pass *fdb.transaction to finalizer func()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@johscheuer I think I specified the wrong object; I changed my approach now.
0bc973a
to
74079ff
Compare
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr on Linux CentOS 7
|
This a marginal improvement which follows the C API documentation: > It is not necessary to commit a read-only transaction – you can simply call fdb_transaction_destroy(). Read-only transactions will be always destroyed before returning to caller, without relying on Go garbage collection; the read-only transactions can be destroyed so early because futures created within them must never be used outside of them.
74079ff
to
d1644f4
Compare
Do not commit read-only transactions following the C API documentation:
No forms of testing were done as I cannot locate a test suite for the Go bindings; would be happy to contribute some in a separate PR.
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branch
ormain
if this is the youngest branch)