+1 on abortTransaction (or rollbackTransaction) approach. In iceberg-cpp we also found that Transaction needs a proper api to clean up the staged transaction when it cannot or fails to commit. This api looks like a perfect fit.
On Mon, Feb 23, 2026 at 8:29 AM Maninder Parmar <[email protected]> wrote: > > +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
