Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121904
MIME-Version: 1.0
References: <6A2118D9-6DD0-4273-A2C0-A1088C05314D@sakiot.com>
 <SN1PR12MB2573419D0ACE231E4C20FB1DDB82A@SN1PR12MB2573.namprd12.prod.outlook.com>
 <A86FDD56-92FE-4FDE-B786-590F0C89136A@sakiot.com> <6cfba3c2-c754-422f-8031-0f6046f828ac@app.fastmail.com>
 <CA+hqhpcG6sz7r+7bHMxF+wuw+maForTMkj+z+jY9_jnDB_b8kw@mail.gmail.com>
 <CADK1yXKX_oyFuy=+z52ECxF56yTBBsqYokDrPOOM2GwycOm0tQ@mail.gmail.com> <CAM0Ccxh52na+Z3e2Nfa_4ZSE-e+1Ac-AWAw+BOVBT2G1V0rqZw@mail.gmail.com>
In-Reply-To: <CAM0Ccxh52na+Z3e2Nfa_4ZSE-e+1Ac-AWAw+BOVBT2G1V0rqZw@mail.gmail.com>
Reply-To: Kentaro Takeda <takeda@youmind.jp>
Date: Sat, 2 Dec 2023 19:35:17 +0900
Message-ID: <CAON3zHDkgV3aQ6r4mEkbdm-wAPPTa_FB6TsNeYYkF5ppJBnO9w@mail.gmail.com>
To: Eugene Sidelnyk <zsidelnik@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, Bruce Weirdan <weirdan@gmail.com>, 
	php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PDO] 2 phase commit
From: internals@lists.php.net ("Kentaro Takeda via internals")

Hi Eugene.

> 1. We have sent commit to the first database and it responded us with OK =
(comitted)
> 2. Next we send commit to the second database, and it may be the case tha=
t in that very moment we lose connection. Hence, if connection is lost befo=
re final commit request, second database won't receive commit, and since It=
's not aware of whether transaction should be committed or rolled back, dat=
a is never made persistent.
>
> FWIK, this case is usually handled at the application level using async c=
ommit in message consumers. Meaning commit operation will be retied again, =
and again, and again until the connection is restored.
>
> Therefore, commit point is the point of no-return and network issues is t=
he problem we have to deal with.

This point highlights a critical and common challenge in deciding
whether to commit to a database.

Moreover, this consideration applies broadly to any side effects on
external systems, not solely to databases or two-phase commits.

Since the solution method differs depending on the system requirements
and specifications, I think developers should ensure safety through
their own implementation, and in other words, there is no need to
consider it as a capability of PHP itself.

Consider, for instance more generally, the following scenarios where
unintended loss of connectivity and processing interruptions are
critical.

* Send multiple HTTP requests with side-effects to external APIs at
the same time. If the connection is lost before the response is
returned.
* Processes that acquire locks, such as by creating a file in the
filesystem, rather than using locks from RDBMS, Redis, etc. If the
process is terminated abnormally by the OS while locked, it becomes
difficult to determine if the file's presence is due to an unfinished
process or an abnormal termination.

In both scenarios, consistency will be checked using another process
equivalent to the message consumers you mentioned, or some other
method.

In the case of a two-phase commit as well, I think that PHP itself MAY
do nothing (or SHOULD NOT do anything).

Regarts.

Kentaro Takeda