From: Justin Tobler <jltobler@gmail.com>
Date: Wed, 04 Feb 2026 17:50:29 GMT
Subject: Re: [PATCH v2 4/4] odb: transparently handle common transaction behavior
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:
> 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