[WIP] Fix: Corrected and optimized pdo_firebird transaction handling.
#12657
Conversation
|
Some tests failed. It seems there is still room for improvement. done |
|
Hmm. The timeout may be caused by starting a transaction in the constructor. It seems likely that I will either have to allow a timeout or change the implementation. I am implementing this to reduce the overhead when starting a transaction, but I think I need to think about it a bit. Maybe it's because the mock server doesn't assume transactional operations. For this test, I try turning off autocommit. done |
|
@Girgias |
SakiTakamachi
force-pushed
the
fix/pdo_firebird_transation
branch
from
e7e52c3 to
10b02c5
Compare
|
|
SakiTakamachi
force-pushed
the
fix/pdo_firebird_transation
branch
from
5df0e41 to
f0ca8ff
Compare
|
There doesn't seem to be a fix anymore. |
SakiTakamachi
changed the title
pdo_firebird transaction handling.pdo_firebird transaction handling.
|
It seems better to merge the error handling changes first, so I'll make this a draft. |
take2 of #12657 ## About Firebird transaction Firebird is a full transactional database, so the DB itself does not support autocommit mode. (Strictly, there is an autocommit mode, but it is a different concept from the "autocommit" that we are used to with MySQL and others.) Therefore, a transaction must have started before any operation is performed, and autocommit mode had to be emulated in PHP. I made sure that a transaction always exists when in autocommit mode. Since the `in_transacntion` function does not work as expected, I have introduced `H->in_manually_txn` to determine whether a transaction is being manually manipulated. ## There are two types of commit/rollback (I'm not talking about two-phase commit. This change does not take into account two-phase commit.) There are `isc_commit_retaining` which starts a transaction again in the same context immediately after committing, and `isc_commit_transaction` which closes the transaction as is. Similarly, there are two types of rollback. ----------- Due to the default value of the transaction isolation level, autocommit mode may obtain unintended results. Regarding this, it would be too large to include support for transaction isolation levels in this PR, so I will leave it as is for now.
Follow up #12545
Firebird doesn't have anything like an autocommit mode, so we need to implement such behavior on the pdo side. Also, whatever we do with firebird, we must operate within a transaction.
This means that in many cases a transaction must already be started in order to achieve autocommit mode.
To begin with, I'm a little doubtful that there's a need to emulate autocommit mode with pdo since it doesn't exist in firebird. I'm starting to feel like it's okay to decide that autocommit mode is not supported.I was able to implement it