LuciferYang opened a new issue, #14602: URL: https://github.com/apache/gravitino/issues/14602
### Version main branch ### Describe what's wrong `GravitinoConnector.beginTransaction` and `commit` forward to the internal Trino connector, but `rollback` does not: `GravitinoConnector` has no `rollback` override, and the SPI default `Connector.rollback` does nothing. So when Trino aborts a transaction (a failed or cancelled query, `ROLLBACK`, or an expired idle transaction), the internal connector never sees it. In Trino 469 to 483, the Hive, Iceberg and JDBC connectors keep a per-transaction entry that only `commit` or `rollback` removes (`HiveTransactionManager`, `IcebergTransactionManager`, `JdbcTransactionManager`), so: - Hive, Iceberg, MySQL and PostgreSQL catalogs keep one transaction entry, with its metadata objects, on the coordinator for every aborted transaction. - Hive skips `SemiTransactionalHiveMetastore.rollback`, which deletes the files the query wrote or staged. - MySQL and PostgreSQL skip `JdbcMetadata.rollback`, which drops the temporary table of a failed `INSERT` or `CREATE TABLE AS`. ### Error message and/or stacktrace None. Nothing fails; the state is left behind. ### How to reproduce From the code: abort any transaction on a Gravitino catalog backed by Hive, Iceberg, MySQL or PostgreSQL, for example a failing `INSERT INTO`. `GravitinoConnector` does not call `rollback` on the internal connector, so the internal transaction manager keeps the transaction's entry. Not reproduced on a cluster. ### Additional context Forwarding is safe: `beginTransaction` begins the internal transaction before it returns the handle, and Trino calls `rollback` at most once, never after `commit`. -- 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]
