Email list hosting service & mailing list manager

How to do transactions, especially nested hga@xxxxxx (18 Sep 2019 01:22 UTC)
Re: How to do transactions, especially nested Peter Bex (18 Sep 2019 06:05 UTC)
Re: How to do transactions, especially nested Lassi Kortela (18 Sep 2019 07:41 UTC)
Re: How to do transactions, especially nested Peter Bex (18 Sep 2019 07:58 UTC)
Re: How to do transactions, especially nested Lassi Kortela (18 Sep 2019 08:26 UTC)
Re: How to do transactions, especially nested Alaric Snell-Pym (18 Sep 2019 10:27 UTC)
Re: How to do transactions, especially nested Alaric Snell-Pym (18 Sep 2019 10:26 UTC)
Re: How to do transactions, especially nested hga@xxxxxx (18 Sep 2019 15:54 UTC)

Re: How to do transactions, especially nested Alaric Snell-Pym 18 Sep 2019 10:25 UTC
On 18/09/2019 08:41, Lassi Kortela wrote:
> For this purpose, transactions also do not need to be nested on the
> database side. It's enough for Scheme to keep a "reference count" of how
> many transactions deep we are, and just create a DB engine transaction
> at the outermost level and commit/rollback at the outermost level.
>
> There are probably some exotic situations where you'd want to use those
> Postgres savepoints at the DB engine side to rollback only part of a
> transaction. I don't know anything about that; I'll let you decide.

Weellll, that's a slightly different thing...

If the semantics of with-transaction are that its contents are either
committed or aborted atomically etc, then it needs to be properly nested
at the DB level when nested in the Scheme code.

If some DBs support nested transactions and some don't, then we have an
issue as to how to make sure that user applications don't have different
behaviour on different databases in ways that cause bugs.

If a nested with-transaction succeeds on a database engine that doesn't
support nested transactions, then we get away with it; the problem is
when a nested with-transaction aborts and the enclosing code retries
with different parameters to make it succeed, all within an outer
with-transaction. Without nested transactions at the DB level, we are
unable to roll back the first failed attempt.

So database drivers that don't support nested transactions should
*probably* error on a nested with-transaction... but arguably, they
could just error on the *failure* of a nested with-transaction, forcing
the entire outermost with-transaction to be aborted?

>> Let's please avoid macros unless absolutely necessary!  Macros don't
>> compose, but procedures do.
>
> I'm neutral on this. If there's a macro, it may be good to include an
> equivalent procedure just in case.

It's possible to have:

(call-with-transaction THUNK)

and:

(with-transaction BODY...) ==> (call-with-transaction (lambda () BODY...))

as syntactic sugar. *shrugs*

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/