The KDocs and the name for the property Transaction.repetitionAttempts makes it seem like setting the value to 1 means that any failed transaction would undergo 1 automatic retry or repeated attempt.
Instead, setting the value to 1 means that the transaction is only run once, without any repetition or retry, and any failure is thrown. Example logic in source code
The property, and its related delay and default variants, are being deprecated in favor of properties that are more aligned with their underlying purpose and the common naming conventions of other standard retry tools/plugins/frameworks:
repetitionAttempts -> maxAttempts
minRepetitionDelay -> minRetryDelay
maxRepetitionDelay -> maxRetryDelay
These properties are being replaced in 3 places:
DatabaseConfig and its helper builder class
Transaction class
TransactionManager interface and its implementations
Breaking Changes:
If maxAttempts is meant to be the amount of attempts to run a transaction, then it may seem like setting the property to 0 should disable a transaction from being performed. This is not the case, as the transaction is always run at minimum once. Now, setting the property (or the deprecated version) to a value less than 1 throws an exception.
The deprecated properties were moved out from the constructor of DatabaseConfig.Builder to allow getters and setters to be added. They were replaced by the new properties that accept the same type of argument. This should be a minor change as the Builder class constructor is not meant to be used directly.
The KDocs and the name for the property
Transaction.repetitionAttemptsmakes it seem like setting the value to 1 means that any failed transaction would undergo 1 automatic retry or repeated attempt. Instead, setting the value to 1 means that the transaction is only run once, without any repetition or retry, and any failure is thrown. Example logic in source codeThe property, and its related delay and default variants, are being deprecated in favor of properties that are more aligned with their underlying purpose and the common naming conventions of other standard retry tools/plugins/frameworks:
repetitionAttempts->maxAttemptsminRepetitionDelay->minRetryDelaymaxRepetitionDelay->maxRetryDelayThese properties are being replaced in 3 places:
DatabaseConfigand its helper builder classTransactionclassTransactionManagerinterface and its implementationsBreaking Changes:
maxAttemptsis meant to be the amount of attempts to run a transaction, then it may seem like setting the property to 0 should disable a transaction from being performed. This is not the case, as the transaction is always run at minimum once. Now, setting the property (or the deprecated version) to a value less than 1 throws an exception.DatabaseConfig.Builderto allow getters and setters to be added. They were replaced by the new properties that accept the same type of argument. This should be a minor change as theBuilderclass constructor is not meant to be used directly.