Skip to content
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

ManageConnection.has_broken implementation #14

Closed
gwenn opened this issue Jul 5, 2015 · 3 comments
Closed

ManageConnection.has_broken implementation #14

gwenn opened this issue Jul 5, 2015 · 3 comments

Comments

@gwenn
Copy link

gwenn commented Jul 5, 2015

Hello,
What is the expected behaviour for an has_broken implementation ?
Should the connection be dropped explicitly when broken ?
Should the connection be considered broken when:

  • there is a pending transaction
  • there are busy statements
    ?

I am trying to create an adaptor for SQLite:
https://github.com/gwenn/r2d2-sqlite.

Regards

@sfackler
Copy link
Owner

sfackler commented Jul 5, 2015

If has_broken returns true, the pool will dispose of the connection. The expected behavior is that has_broken should return true if the connection is determined to be broken to the point where it is very unlikely that it would be usable in the future, and it should determine that quickly - with no network or filesystem IO, for example. The implementation for r2d2-postgres checks to see if there have been any IO errors communicating with the database - if so, the communication stream has desynchronized so any further queries will almost certainly fail.

I'm not sure if there's an equivalent state in SQLite since it's talking directly to the filesystem. It may just make sense for your implementation to return false.

@gwenn
Copy link
Author

gwenn commented Jul 5, 2015

Ok,
There is only memory status check when calling sqlite3_getautocommit and sqlite3_stmt_busy.
What happens if a transaction is pending when a postgresql connection is returned to the pool ?

BEGIN;
INSERT INTO foo (bar) VALUES (1);
-- connection released

Thanks.

@sfackler
Copy link
Owner

sfackler commented Jul 5, 2015

It will continue to be in a transaction. Transactions are managed through an RAII based API that will statically prevent an active transaction if that API is used. If someone manually executes a BEGIN and forgets the accompanying COMMIT or ROLLBACK, nothing currently checks for that fact.

@gwenn gwenn closed this as completed Jul 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants