Re: [PATCH v2 4/4] odb: transparently handle common transaction behavior

From: Justin Tobler <jltobler@gmail.com>
Date: Feb 4, 2026, 17:50 UTC
Message-ID: <aYOEQUIPXPIYeCw-@denethor>
In-Reply-To: <CAOLa=ZT_7o_YquQ_mAg6sn=gq0Rx4Tga4vNsVsPt3jCUh=3tzw@mail.gmail.com>

On 26/02/04 10:34AM, Karthik Nayak wrote:

Show 13 quoted lines

> Justin Tobler <jltobler@gmail.com> writes:
> 
> > A new ODB transaction is created and returned via
> > `odb_transaction_begin()` and stored in the ODB. Only a single
> > transaction may be pending at a time. If the ODB already has a
> > transaction, the function is expected to return NULL. Similarly, when
> > committing a transaction via `odb_transaction_commit()` the transaction
> > being committed must match the pending transaction and upon commit reset
> > the ODB transaction to NULL.
> 
> But isn't this merely a limitation of the current implementation of the
> files transactions? Couldn't a potential ODB source support parallel
> transactions where this might no longer hold?

Just to clarify, this limitation exists per Git process. For the time being, we only support writing objects to a single ODB source so a single transaction for object writes seems reasonable for now. Furthermore, the current "files" transaction backend relies on the tmp_odjdir subsystem which means only a single temp odjdir may exist for a Git process to write objects to.

-Justin