Skip to content

Clean connections that are returned to connection pool #4191

Open
@smklein

Description

@smklein

See @davepacheco 's comment on : #4093 (comment) for some context:

Sorry, what I meant was not to try to track whether a transaction was created, but rather always issue ROLLBACK when a connection is put back into the pool. This will fail if there was no open transaction and we'd ignore the error in this context. This would be a fallback to catch cases like this, rather than relying on the consuming code to have correctly tracked this information.

What I meant about common practice is that I think other connection pools have the notion of "stuff that gets done when a connection gets put back into the pool to ensure that connections all come out of the pool in a consistent state". Here's an example from deadpool's PostgreSQL crate:
https://docs.rs/deadpool-postgres/latest/deadpool_postgres/enum.RecyclingMethod.html

They provide a few different choices with tradeoffs in terms of cost vs. completeness. RecyclingMethod::Fast does basically nothing. RecyclingMethod::Clean runs several SQL statements that close open cursors, reset any connection-local parameters that were set with set, unlock any locks that were somehow left locked, etc. (I'm surprised they don't seem to do a rollback!)

I could not find an equivalent method in bb8, to clean connections. We could upstream this support, or consider an option like #4192

Metadata

Metadata

Assignees

No one assigned

    Labels

    databaseRelated to database access

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions