You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Péter Váry <pe...@gmail.com> on 2026/02/20 13:47:12 UTC
[DISCUSS] Transaction.abortTransaction
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
Re: [DISCUSS] Transaction.abortTransaction
Posted by Steve <ho...@gmail.com>.
+1 to have a clearly defined abortTransaction() method for clean up on
the transaction interface.
On Fri, Feb 20, 2026 at 2:00 PM Denys Kuzmenko <dk...@apache.org> wrote:
>
> abortTransaction() API should be sufficient, no need to open constructor. my bad
Re: [DISCUSS] Transaction.abortTransaction
Posted by Denys Kuzmenko <dk...@apache.org>.
abortTransaction() API should be sufficient, no need to open constructor. my bad
Re: [DISCUSS] Transaction.abortTransaction
Posted by Russell Spitzer <ru...@gmail.com>.
I'm supportive of having the "abort" api, I'd be less excited about opening
up the constructor just because I'm not sure we want to expose ourselves to
that kind of downstream support but I could definitely be convinced if we
had a good use case here.
On Fri, Feb 20, 2026 at 1:37 PM Denys Kuzmenko <dk...@apache.org> wrote:
> Thank you, Peter, for initiating the discussion on this topic! A dedicated
> abortTransactions API sounds even better!
>
> It would also help if we made the BaseTransaction constructor public.
>
> Kind Regards,
> Denys
>
Re: [DISCUSS] Transaction.abortTransaction
Posted by Denys Kuzmenko <dk...@apache.org>.
Thank you, Peter, for initiating the discussion on this topic! A dedicated abortTransactions API sounds even better!
It would also help if we made the BaseTransaction constructor public.
Kind Regards,
Denys
Re: [DISCUSS] Transaction.abortTransaction
Posted by Steve Loughran <st...@cloudera.com>.
a proper abortTransaction() call seems better, as it could make explicit
that after its invocation commit() shall fail
with CommitFailedException. cleanUpOnCommitFailure() doesn't actually do
that, does it?
On Fri, 20 Feb 2026 at 13:47, Péter Váry <pe...@gmail.com>
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
>
Re: [DISCUSS] Transaction.abortTransaction
Posted by Gang Wu <us...@gmail.com>.
+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
<pa...@gmail.com> 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 <ql...@gmail.com> 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 <pe...@gmail.com> 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
Re: [DISCUSS] Transaction.abortTransaction
Posted by Maninder Parmar <pa...@gmail.com>.
+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 <ql...@gmail.com> 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 <pe...@gmail.com>
> 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
>>
>
Re: [DISCUSS] Transaction.abortTransaction
Posted by Qiegang Long <ql...@gmail.com>.
+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 <pe...@gmail.com>
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
>