yuqi1129 commented on PR #13792: URL: https://github.com/apache/gravitino/pull/13792#issuecomment-6167068860
@diqiu50 Agreed that transient contention is better handled on the server when the complete metadata transaction is safely replayable. I propose keeping that as a separate change rather than adding a blanket retry to this classification fix. There are two concrete constraints in the current code: - JDBCBackend writes can join an existing SessionUtils transaction; retrying an inner store call would not roll back/replay the complete transaction in a fresh session. update also accepts a caller-provided function, so its replay safety must be audited rather than assumed. Retrying a manager/dispatcher instead would risk replaying external work. - An elapsed-time check between attempts cannot bound a database statement already waiting for a lock. With MySQL's default 50-second lock wait, attempts alone can exceed the request budget; a bounded design needs to budget the per-attempt database wait as well. The retry implementation should therefore select explicit transaction-owning metadata boundaries, reread/recompute on each attempt, use capped backoff with jitter and both attempt/deadline limits, preserve interruption, and propagate 409 when exhausted. Tests should cover contention that clears, exhaustion, ordinary failures, nested transactions, and no repeated external side effects. This PR retains immediate conflict propagation; job submission and dataset creation are not automatically replayed. I have prepared the same scope and constraints for the PR description. This reply defers the retry implementation; it does not claim that this PR implements server-side retries. -- 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]
