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

Lost DB connection when I use Pony for connect to the remote Postgres database. #219

Closed
vmcfire opened this Issue Jan 12, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@vmcfire

vmcfire commented Jan 12, 2017

Vasiliy Makaganchuk:
Hello everybody. I use Pony for connect to the remote Postgres database. Periodically, the database connection is lost and Pony returns an exception:

File "... / lib / python2.7 / site-packages / pony / orm / core.py", line 1566, in close
try: provider.rollback (connection, cache)
File "<auto generated wrapper of rollback () function>", line 2, in rollback
File "... / lib / python2.7 / site-packages / pony / orm / dbapiprovider.py", line 59, in wrap_dbapi_exceptions
raise InterfaceError (e)
RollbackException: InterfaceError: connection already closed

After that, Pony automatic reconnect, but my function call is aborted.

Is it possible to test the connection and forced to reconnect? I have not found the necessary methods in Pony docs. Maybe you need to look at psycopg2 docs?

@vmcfire

This comment has been minimized.

Show comment
Hide comment
@vmcfire

vmcfire Jan 12, 2017

Alexander Kozlovsky:
Hi Vasiliy! Pony should be able to reconnect automatically, if the connection was lost not in the middle of transaction.

I think that your problem caused by the following sequense of actions:

  1. An application code performs some query;
  2. Due to some problem in configuration (for example, an insufficient size of some buffer) the server drops the connection, and Pony gets an exception from psycopg2;
  3. Exception unrolling leads to exiting from db_session;
  4. Pony tries to handle exit from db_session and attempts to peform rollback, assuming that the connection is stlii active;
  5. At this moment we got another exception, "connection already closed" which masks previous exception.

I think we need to improve handling of rollback so it does not mask previous exception in case the connection is closed already.

Regarding your situation, I think the right way is not to attempt to reconnect, but to prevent an exception which lead to connection closing. After we fix handling of rollback, you should be able to see this original exception and will be able to fix its root

vmcfire commented Jan 12, 2017

Alexander Kozlovsky:
Hi Vasiliy! Pony should be able to reconnect automatically, if the connection was lost not in the middle of transaction.

I think that your problem caused by the following sequense of actions:

  1. An application code performs some query;
  2. Due to some problem in configuration (for example, an insufficient size of some buffer) the server drops the connection, and Pony gets an exception from psycopg2;
  3. Exception unrolling leads to exiting from db_session;
  4. Pony tries to handle exit from db_session and attempts to peform rollback, assuming that the connection is stlii active;
  5. At this moment we got another exception, "connection already closed" which masks previous exception.

I think we need to improve handling of rollback so it does not mask previous exception in case the connection is closed already.

Regarding your situation, I think the right way is not to attempt to reconnect, but to prevent an exception which lead to connection closing. After we fix handling of rollback, you should be able to see this original exception and will be able to fix its root

@kozlovsky kozlovsky self-assigned this Jan 12, 2017

@kozlovsky kozlovsky added the bug label Jan 12, 2017

@kozlovsky kozlovsky added this to the 0.8 milestone Jan 12, 2017

@kozlovsky kozlovsky closed this in 1146ff1 Jan 13, 2017

@kozlovsky

This comment has been minimized.

Show comment
Hide comment
@kozlovsky

kozlovsky Jan 13, 2017

Member

Thanks for reporting, I fixed it. Previously the "connection already closed" exception masked the original exception which causes the connection closing. Now you can see the reason for connection closing, and if it is caused by some bug in Pony you can open another issue related to that specific problem.

Member

kozlovsky commented Jan 13, 2017

Thanks for reporting, I fixed it. Previously the "connection already closed" exception masked the original exception which causes the connection closing. Now you can see the reason for connection closing, and if it is caused by some bug in Pony you can open another issue related to that specific problem.

kozlovsky added a commit that referenced this issue Jul 17, 2017

Pony ORM Release 0.7.2 (2017-07-17)
# New features

* All arguments of db.bind() can be specified as keyword arguments. Previously Pony required the first positional argument which specified the database provider. Now you can pass all the database parameters using the dict: db.bind(**db_params). See https://docs.ponyorm.com/api_reference.html#Database.bind
* The `optimistic` attribute option is added https://docs.ponyorm.com/api_reference.html#cmdoption-arg-optimistic

# Bugfixes

* Fixes #219: when a database driver raises an error, sometimes this error was masked by the 'RollbackException: InterfaceError: connection already closed' exception. This happened because on error, Pony tried to rollback transaction, but the connection to the database was already closed and it masked the initial error. Now Pony displays the original error which helps to understand the cause of the problem.
* Fixes #276: Memory leak
* Fixes the __all__ declaration. Previously IDEs, such as PyCharm, could not understand what is going to be imported by 'from pony.orm import *'. Now it works fine.
* Fixes #232: negate check for numeric expressions now checks if value is zero or NULL
* Fixes #238, fixes #133: raise TransactionIntegrityError exception instead of AssertionError if obj.collection.create(**kwargs) creates a duplicate object
* Fixes #221: issue with unicode json path keys
* Fixes bug when discriminator column is used as a part of a primary key
* Handle situation when SQLite blob column contains non-binary value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment