singhpk234 commented on code in PR #1517:
URL: https://github.com/apache/polaris/pull/1517#discussion_r2074461532
##########
extension/persistence/relational-jdbc/src/main/java/org/apache/polaris/extension/persistence/relational/jdbc/DatasourceOperations.java:
##########
@@ -173,23 +190,82 @@ public int executeUpdate(String query) throws
SQLException {
* @throws SQLException : Exception caught during transaction execution.
*/
public void runWithinTransaction(TransactionCallback callback) throws
SQLException {
- try (Connection connection = borrowConnection()) {
- boolean autoCommit = connection.getAutoCommit();
- connection.setAutoCommit(false);
- boolean success = false;
+ withRetries(
+ () -> {
+ try (Connection connection = borrowConnection()) {
+ boolean autoCommit = connection.getAutoCommit();
+ boolean success = false;
+ connection.setAutoCommit(false);
+ try {
+ try (Statement statement = connection.createStatement()) {
+ success = callback.execute(statement);
+ }
+ } finally {
+ if (success) {
+ connection.commit();
+ } else {
+ connection.rollback();
+ }
+ connection.setAutoCommit(autoCommit);
+ }
+ }
+ return null;
+ });
+ }
+
+ private boolean isRetryable(SQLException e) {
+ String sqlState = e.getSQLState();
+
+ if (sqlState != null) {
+ return sqlState.equals(DEADLOCK_SQL_CODE)
+ || // Deadlock detected
+ sqlState.equals(SERIALIZATION_FAILURE_SQL_CODE); // Serialization
failure
+ }
+
+ // Additionally, one might check for specific error messages or other
conditions
+ return e.getMessage().contains("connection refused")
+ || e.getMessage().contains("connection reset");
+ }
+
+ public <T> T withRetries(Operation<T> operation) throws SQLException {
+ int attempts = 0;
+ // maximum number of retries.
+ int maxAttempts = relationalJdbcConfiguration.maxRetries().orElse(1);
Review Comment:
My reasoning for this is, Since we are randomizing the retry duration, we
strictly can't restrict number of retries ? if i am constrained by lets say
number of concurrent connection having no control on retries count might leave
this a bit unpredictable for planning the concurrent connection we wanna
support, hence bounded by maxRetries
This serves as a middle ground, helps both the user who wanna rely just on
max retries (by setting max duration to something very big) or retry just on
max duration or have combination of both.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]