+1 on explicit abortTransaction (preferably rollbackTransaction), I also want us to consider safer ownership semantics by making Transaction extend AutoCloseable. This would promote using try with resource pattern for Transactions which can help prevent file leaks when someone forgets to close the transaction since we can implement the close method to call the proposed abortTransaction API
On Sun, Feb 22, 2026 at 9:23 AM Qiegang Long <[email protected]> wrote: > +1 on explicit abortTransaction. Just wondering if rollback might be a > better name if we ever want to support savepoint in the future? > > Qiegang > > On Fri, Feb 20, 2026, 8:48 AM Péter Váry <[email protected]> > wrote: > >> Hi Team, >> >> I was recently contacted by Denis from the Hive project. Their team is >> implementing multi‑table transactions guarded by Hive locks. When they fail >> to acquire locks for all tables so the transaction ultimately fails, they >> want to revert the individual partial changes. Today this cleanup is >> handled by `BaseTransaction.cleanUpOnCommitFailure`. >> >> They asked whether we could make this method protected [1], so classes >> extending BaseTransaction could invoke it and remove unused files. >> >> While this would be a quick and simple fix for their use case, it feels >> more natural to expose a new `Transaction.abortTransaction()` method on the >> public Transaction API. That way, cleanup would be performed explicitly >> when a user chooses to roll back rather than commit. >> >> What do you think? >> >> Thanks, >> Peter >> >> [1] - https://github.com/apache/iceberg/issues/15377 >> >
