-
Notifications
You must be signed in to change notification settings - Fork 101
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
IGNITE-24242 Add RO/RW Transaction Timeout configuration schema #5093
base: main
Are you sure you want to change the base?
Conversation
2b826b9
to
68f1fa8
Compare
private final long roTransactionTimeout; | ||
|
||
private final long rwTransactionTimeout; |
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.
Should we allow these timeouts to be changed at runtime?
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.
I assume that txTimeout is tx attribute and not tableManager/InternalTableImpl, meaning that different transactions may have different timeouts. Adjustable defaults should populate tx on start. More details in the comment above.
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.
+1. we should
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long implicitTransactionTimeout = 3_000; | ||
public final long minRoTimeout = 1; |
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.
- Javadocs are missing
- Abbreviations like RO and RW look ugly in user-facing API. Should we name them
readOnlyXXX
andreadWriteXXX
?
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.
+1. we should
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.
done
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we still can do breaking changes in configuration APIs.
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.
timeout
removed
@@ -418,7 +418,9 @@ public class TableManager implements IgniteTablesInternal, IgniteComponent { | |||
|
|||
private final PartitionReplicaLifecycleManager partitionReplicaLifecycleManager; | |||
|
|||
private long implicitTransactionTimeout; | |||
private long roTransactionTimeout; |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to remove implicitTransactionTimeout
private final long roTransactionTimeout; | ||
|
||
private final long rwTransactionTimeout; |
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.
I assume that txTimeout is tx attribute and not tableManager/InternalTableImpl, meaning that different transactions may have different timeouts. Adjustable defaults should populate tx on start. More details in the comment above.
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRoTimeout = Long.MAX_VALUE; |
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.
Why it's not equal to dataAvailabilityTime?
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.
(deleted as irrelevant)
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.
property deleted
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRwTimeout = Long.MAX_VALUE; |
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.
Is it too much for default max value?
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.
property deleted
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRoTimeout = Long.MAX_VALUE; |
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.
Here and there: for such properties it's reasonable to have milis(or any other) suffix.
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
property deleted
private final long roTransactionTimeout; | ||
|
||
private final long rwTransactionTimeout; |
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.
+1. we should
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRoTimeout = Long.MAX_VALUE; |
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.
What is the purpose of
minRoTimeout maxRoTimeout minRwTimeout maxRwTimeout ?
It doesn't make sense to me.
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.
I agree. Will drop these properties.
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long implicitTransactionTimeout = 3_000; | ||
public final long minRoTimeout = 1; |
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.
+1. we should
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion.
…e updated, we will use up-to-dated values.
https://issues.apache.org/jira/browse/IGNITE-24242