yuqi1129 opened a new issue, #13776:
URL: https://github.com/apache/gravitino/issues/13776
### Describe the subtask
Deadlocks and lock-wait timeouts in the relational entity store surface as
raw store failures (HTTP 500) on every write path except statistics. Only
`StatisticMetaService` maps them to `OptimisticLockException` (HTTP 409, code
1012), through `isConcurrencyFailure`.
Since writes fence on parent and endpoint rows inside the database (#13004,
#13487, #13737), unrelated writers can queue on the same row. The main example
is a table drop and a table-scoped write: a statistic update, or a tag or
policy association. The drop's first statement updates the table row that the
other write holds. When that wait exceeds the backend lock timeout (H2 uses a
short default, and the shipped default backend is H2), the drop fails with HTTP
500. The statistic side of the same race gets 409. With the tree lock removed,
this now also happens on a single server.
Proposal:
- Classify concurrency failures once, in the shared store exception path
(`ExceptionUtils.checkSQLException` or an equivalent):
- deadlock or serialization failure: SQLState 40001 / 40P01, MySQL 1213
- lock-wait timeout: MySQL 1205, PostgreSQL 55P03, H2 50200 (SQLState
HYT00)
- Map them to `OptimisticLockException` for every write, so the whole
transaction is rolled back and reported as a retryable conflict. Reuse the
statistic classification instead of copying it.
- Tests: a real lock-wait timeout on H2 (hold the row `FOR UPDATE` from
another session), and an injected deadlock on MySQL/PostgreSQL. Cover at least
a table drop racing a table-scoped write.
### Parent issue
https://github.com/apache/gravitino/issues/13730
--
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]
