Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Recycle NpgsqlTransaction #2416
PostgreSQL doesn't support more than one transaction on a given connection at any given time. This means that each connector can have a single NpgsqlTransaction instance, and return that every time
When we end up implementing
Note that this is a slightly user-visible change, in that a user holding a reference to an NpgsqlTransaction will suddenly see the instance "revived" when
More importantly, this would make the
This would make it the user's responsibility to track the transaction state, and not call rollback on it twice (doing so would trigger an exception). If an intermediate layer is causing the rollback (as in #985), the user would need to be aware of that and refrain from calling rollback again. While this would make life a bit more difficult for users, it seems to make sense for the perf gain. Note that this is an Npgsql-specific API, not ADO.NET (introduced in #985).
referenced this issue
Apr 4, 2019
Since the underlying behavior of transactions is changing, it does make sense to remove this property from the API as we can no longer assume the NpgsqlTransaction object belongs to the same transaction after we release it.
I think it is reasonable to require the framework to either remove all special handling in the framework side so the transaction isn't released and reused early or as you say keep track of this in some other way to prevent the double rollback problem. For that either a structure could be used, or just removing the NpgsqlTransaction object.
Sorry for the delay. From what I recall about the issue, we did have to fix it on our side since we couldn't wait on the release of the patch and we prefer to use official builds for production, but we did migrate our solution to Npgsql's once it was released. The reasoning behind bringing it to Npgsql at all was due to it having the ultimate knowledge of its own state and the feeling that other people could benefit from making that Connnector == null call more transparent (since connector was private on the transaction object if i recall correctly). We obviously cannot rely on this property any more and will need to re-examine our old solution.