feat: support read lock mode for R/W transactions #4010
Conversation
product-auto-label
bot
added
size: l
shobhitsg
force-pushed
the
read_lock_mode
branch
from
1c38bc5 to
42c86b0
Compare
google-cloud-spanner/src/main/java/com/google/cloud/spanner/SpannerOptions.java
Show resolved
Hide resolved
shobhitsg
force-pushed
the
read_lock_mode
branch
from
42c86b0 to
9fd5cb1
Compare
google-cloud-spanner/src/main/java/com/google/cloud/spanner/Options.java
Outdated
Show resolved
Hide resolved
sakthivelmanii
added
the
kokoro:force-run
yoshi-kokoro
removed
the
kokoro:force-run
| * | ||
| * <ul> | ||
| * <li>{@link ReadLockMode#PESSIMISTIC}: Read locks are acquired immediately on read. This mode | ||
| * primarily applies to transactions with {@code SERIALIZABLE} isolation. |
There was a problem hiding this comment.
What does this sentence mean?
This mode primarily applies to transactions with {@code SERIALIZABLE} isolation.
That it has no effect on RR? Or that it has a strong effect on Serializable?
What I'm aiming at is: Can we make this more concrete? As a customer, I would have no idea what this means.
There was a problem hiding this comment.
I've updated the doc. Currently, we do not allow setting the readLockMode for Repeatable Read(RR) isolation level and error will be returned. And by default, OPTIMISTIC lock mode will be used for RR.
google-cloud-spanner/src/main/java/com/google/cloud/spanner/Options.java
Outdated
Show resolved
Hide resolved
google-cloud-spanner/src/main/java/com/google/cloud/spanner/Options.java
Outdated
Show resolved
Hide resolved
google-cloud-spanner/src/main/java/com/google/cloud/spanner/Options.java
Outdated
Show resolved
Hide resolved
| /** | ||
| * Returns a {@link TransactionOption} to set the desired {@link ReadLockMode} for a read-write | ||
| * transaction. | ||
| * |
There was a problem hiding this comment.
Can we also add some generic advice when to use what? (Otherwise, I think that most users will automatically assume that 'optimistic is always better than pessimistic').
So for example something like this:
| * | |
| * Optimistic locking can improve throughput, as transactions wait with taking locks until they try to commit, | |
| * but increases the probability that Spanner needs to abort a transaction due to lock conflicts. Pessimistic | |
| * locking instructs transactions to take locks earlier, which means that concurrent transactions might have | |
| * to wait for other transactions to release locks before proceeding. Pessimistic locking reduces the probability | |
| * that Spanner needs to abort a transaction due to lock conflicts. |
There was a problem hiding this comment.
I initially added some advice to the document but removed it because I felt it deserved a more detailed explanation in a separate link. I've now added the advice back, and we will update this document once the RR + Pessimistic feature is launched.
google-cloud-spanner/src/main/java/com/google/cloud/spanner/SessionImpl.java
Outdated
Show resolved
Hide resolved
google-cloud-spanner/src/main/java/com/google/cloud/spanner/SpannerOptions.java
Outdated
Show resolved
Hide resolved
|
@sakthivelmanii @olavloite: I've addressed the review comments. PTAL. |
Samples and integration tests will be added in separate PRs.