-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix begin trasaction after reconnect #3679
fix begin trasaction after reconnect #3679
Conversation
@kalinin-k-a please turn the scenario in the description into a test. |
done |
Why are there 2 PRs for this? #3679 looks the same, but on another branch and without tests, which one is the right one? |
Please squash your commits
Please explain in your commit message what was wrong, and why your changes fix that situation. Maybe
|
Another is into v2.5. I'll also write tests |
f3d74d2
to
d4bfeab
Compare
Please associate your email address with your Github account, or change the email in your commits to an address already associated with it. |
d4bfeab
to
e88cf34
Compare
commits are squashed, email is changed. Thank you for reminding ! |
e88cf34
to
58bd4a5
Compare
pushed again because mysql server had gone away during functional tests previously |
$this->connection->beginTransaction(); // should connect, reset nesting level and increase it once | ||
self::assertEquals(1, $this->connection->getTransactionNestingLevel()); | ||
$this->connection->commit(); | ||
self::assertEquals(0, $this->connection->getTransactionNestingLevel()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the scenario from the description. The test as it's written now does not reflect the actual issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure that scenario from description is good for test. It just shows one case that may be affected by nesting level issue. Also the result from the description may happen if for example commit works wrong.
I fixed nesting level reset, so i tested the same.
Do you insist on change test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without that case, it's not clear why we want to reset the transaction nesting level after establishing a connection. The level is an internal implementation detail of the DBAL, it doesn't have to be tested in a functional way but I'd rather have a functional case which relies on it. Even if it's just one case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
Strange, but Insert statement fails the test now with "Table not found". Seems like table exist only before closing connection in testing environment. I'll look again a little later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. It was sqlite connection with memory=true. Please review once more
4a3bc6b
to
9b918da
Compare
3f2e227
to
6456e69
Compare
$this->connection->beginTransaction(); | ||
$connection->close(); // connection closed in runtime (for example if lost or another application logic) | ||
|
||
$connection->beginTransaction(); // should connect, reset nesting level and increase it once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment doesn't seem relevant to what the test is about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Should realy start the transaction, and the rollback() call below realy leads to rollback it " - better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The transaction nesting level could be checked here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Should realy start the transaction, and the rollback() call below realy leads to rollback it " - better?
Just remove the comment. The previous one says enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok,. done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm… it's still there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, it really was. Forgot to commit, sorry. Now it's realy done)
$connection->executeQuery('insert into test_nesting values (33)'); | ||
$connection->rollback(); | ||
|
||
self::assertEquals(0, $connection->fetchColumn('select count(*) from test_nesting')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the transaction nesting level be checked here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. The fact that the transaction was successfully rolled back is enough. The nesting level is an implementation detail in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the transaction nesting level be checked here too?
The exact values of nestingLevel is completely tested in testTransactionNestingBehavior()
$this->connection->beginTransaction(); | ||
$connection->close(); // connection closed in runtime (for example if lost or another application logic) | ||
|
||
$connection->beginTransaction(); // should connect, reset nesting level and increase it once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The transaction nesting level could be checked here too.
6456e69
to
3df789f
Compare
When the connection is lost or is closed, subsequent transaction will no longer be nested because they started in a brand new session. Our internal representation of the nesting shold take this into account
3df789f
to
b550879
Compare
Transaction nesting level is tested in another test.
Thank you @kalinin-k-a. |
Release v2.9.3 [![Build Status](https://travis-ci.org/doctrine/dbal.svg?branch=v2.9.3)](https://travis-ci.org/doctrine/dbal) This release fixes regressions introduced in previous releases and other bugs. - Total issues resolved: **5** - Total pull requests resolved: **14** - Total contributors: **9** **Regressions** - [3686: Fixed query result caching when `FetchMode::COLUMN` is used](doctrine#3686) thanks to @morozov and @Junker - [3456: Compare type class when comparing columns.](doctrine#3456) thanks to @garret-gunter and @cs278 **Other bugs** - [3679: fix begin trasaction after reconnect](doctrine#3679) thanks to @kalinin-k-a - [3547: Default column expressions do not work on SQL Server](doctrine#3547) thanks to @morozov - [3420: Index length can be a `string`: ensure that it is an integer when read by the `MySqlSchemaManager`](doctrine#3420) thanks to @leofeyer **CI improvements and maintenance** - [3702: Updated SQL Server extensions to fix build failures on PHP 7.4](doctrine#3702) thanks to @morozov - [3662: Marked connection exception test incomplete on MySQL 8](doctrine#3662) thanks to @morozov - [3622: Switched from ibmcom/db2express-c to ibmcom/db2](doctrine#3622) thanks to @morozov - [3465: Replaced MySQL 5.7 installed from a PPA with an official Docker image](doctrine#3465) thanks to @morozov - [3454: CI: Test against PHP 7.4snapshot instead of nightly (8.0)](doctrine#3454) thanks to @Majkl578 - [3452: Fixed AppVeyor build configuration and the issue on SQL Server](doctrine#3452) thanks to @morozov and @Majkl578 - [3447: Replaced custom docker image for PostgreSQL with the official one](doctrine#3447) thanks to @morozov - [3407: CI: Test against MySQL 8.0 on Travis](doctrine#3407) thanks to @morozov **PHP 7.4 support** - [3642: Fixed test failures on PHP 7.4](doctrine#3642) thanks to @morozov # gpg: Signature made Sat Nov 2 23:20:42 2019 # gpg: using RSA key 374EADAF543AE995 # gpg: Can't check signature: public key not found
Summary
This is a small fix if we lose the connection and work with transactions after reconnect.
The code examples below demonstrate a problem: