IGNITE-24242 Add RO/RW Transaction Timeout configuration schema#5093
IGNITE-24242 Add RO/RW Transaction Timeout configuration schema#5093PakhomovAlexander merged 21 commits intoapache:mainfrom
Conversation
2b826b9 to
68f1fa8
Compare
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
| public final long roTimeout = 10_000; | ||
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long rwTimeout = 3_000; |
There was a problem hiding this comment.
There is already timeout which defines default timeouts. Now, rwTimeout and roTimeout are added. Do they serve the same purpose? If yes, timeout should probably be removed.
But if it's removed, it's a breaking change (as 3.0 code freeze has already happened) and it should be handled in a different way, probably by declaring it as deprecated and, maybe, using the existing value for some time?
There was a problem hiding this comment.
I believe we still can do breaking changes in configuration APIs.
There was a problem hiding this comment.
timeout removed
| private final PartitionReplicaLifecycleManager partitionReplicaLifecycleManager; | ||
|
|
||
| private long implicitTransactionTimeout; | ||
| private long roTransactionTimeout; |
There was a problem hiding this comment.
Tx timeout is tx specific attribute, meaning that tx1 will have 100ms as timeout and tx2 that is running at the same time 2000ms. In that case why roTransactionTimeout and rwTransactionTimeout are here?
Besides that, it's just an encapsulation leak - simply TableManager should not know about such things.
I'd rather say that on tx creation we should populate TransacionOptions with default timeout from cfg if it's not specified by the user and within tx flow use timeout from the tx context - no need to propagate txTimeout to InternalTableImpl etc.
There was a problem hiding this comment.
Do you agree that implicitTransactionTimeout should be removed with this PR? If yes, then it is clear why these options are there. If we should keep implicitTransactionTimeout then, probably, I should rollback the change.
I suppose we should remove implicitTransactionTimeout and refactor TableManager as you suggested. Am I right?
There was a problem hiding this comment.
+1 to remove implicitTransactionTimeout
There was a problem hiding this comment.
In that case why roTransactionTimeout and rwTransactionTimeout are here?
I thought these properties define default TX timeouts. A default is global and not specific to a transaction.
There was a problem hiding this comment.
I suppose we should remove implicitTransactionTimeout and refactor TableManager as you suggested. Am I right?
Yes.
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long maxRoTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
Why it's not equal to dataAvailabilityTime?
There was a problem hiding this comment.
property deleted
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long maxRwTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
Is it too much for default max value?
There was a problem hiding this comment.
property deleted
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long maxRoTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
Here and there: for such properties it's reasonable to have milis(or any other) suffix.
There was a problem hiding this comment.
There was a proposal to switch duration-related properties type to Duration and allow the user specify units in the config. Having this in mind, it seems that we should not include units in property names.
My comment only makes sense if we still want to have that feature in the configuration.
There was a problem hiding this comment.
property deleted
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long maxRoTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
What is the purpose of
minRoTimeout maxRoTimeout minRwTimeout maxRwTimeout ?
It doesn't make sense to me.
There was a problem hiding this comment.
I agree. Will drop these properties.
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
| public final long roTimeout = 10_000; | ||
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long rwTimeout = 3_000; |
There was a problem hiding this comment.
I believe we still can do breaking changes in configuration APIs.
|
|
||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long roTimeout = 10_000; |
There was a problem hiding this comment.
How these defaults are calculated?
They seem too low.
I suggest 10 minutes for RO txns, and 30 seconds for RW txns
There was a problem hiding this comment.
Good suggestion.
…e updated, we will use up-to-dated values.
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
…tx/configuration/TransactionConfigurationSchema.java Co-authored-by: Roman Puchkovskiy <roman.puchkovskiy@gmail.com>
(will be changed in the next ticket)
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
| long ts = (txStartTs == null) ? actualTx.startTimestamp().getPhysical() : txStartTs; | ||
|
|
||
| if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < implicitTransactionTimeout) { | ||
| if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < timeout) { |
There was a problem hiding this comment.
How about extracting the if condition to a method? It's used a few times in this same form
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Show resolved
Hide resolved
| /** Default timeout for read-only transactions. */ | ||
| @Range(min = 1) | ||
| @Value(hasDefault = true) | ||
| public final long timeout = 10_000; |
There was a problem hiding this comment.
This still looks like a breaking change. Let's consult @ptupitsyn whether we are allowed to directly remove a configuration property
There was a problem hiding this comment.
Good catch. But why should we consult Pavel about changing the property we've added a couple of weeks ago?
There was a problem hiding this comment.
Because 3.0.0 already contains transaction.timeout config property. If we just remove it, then our next release will potentially break them.
...sactions/src/main/java/org/apache/ignite/internal/tx/impl/IgniteAbstractTransactionImpl.java
Outdated
Show resolved
Hide resolved
...sactions/src/main/java/org/apache/ignite/internal/tx/impl/IgniteAbstractTransactionImpl.java
Outdated
Show resolved
Hide resolved
|
|
||
| private long roExpirationPhysicalTimeFor(HybridTimestamp beginTimestamp, InternalTxOptions options) { | ||
| long effectiveTimeoutMillis = options.timeoutMillis() == 0 ? defaultTransactionTimeoutMillis() : options.timeoutMillis(); | ||
| long effectiveTimeoutMillis = options.timeoutMillis() == 0 ? defaultReadOnlyTransactionTimeoutMillis() : options.timeoutMillis(); |
There was a problem hiding this comment.
This calculation is repeated at least twice. Let's extract it to a method
There was a problem hiding this comment.
The next ticket will change this, don't you mind to leave this as is?
There was a problem hiding this comment.
I'm ok with this if this will not be forgotten :)
|
|
||
| @Override | ||
| public long timeout() { | ||
| return 10_000; |
There was a problem hiding this comment.
10_000 is used for the same purpose in multiple places. Should we extract it somewhere?
There was a problem hiding this comment.
The next ticket will change this, don't you mind to leave this as is?
…tx/impl/IgniteAbstractTransactionImpl.java Co-authored-by: Roman Puchkovskiy <roman.puchkovskiy@gmail.com>
rpuch
left a comment
There was a problem hiding this comment.
The only concern that still remains from my side is the compatibility issue, let's sort it out
https://issues.apache.org/jira/browse/IGNITE-24242