Cédric Krier
e2676bcd85
When a connection in the pool is disconnected, it stays in the pool and it may still be served. Using such connection raise an OperationalError and so the request is retried but before that the connection is put back to the pool. So we may get it back again. It is not possible to distinct between an OperationalError due to a disconnection or due to a isolation error for example. So with the current design of Transaction API, an OperationalError always put back the connection to the pool. This main that we can only ensure that the connections served are still connected by executing a simple query. And close connections that are failing. Closes #12452
###### Tryton ###### Tryton is business software, ideal for companies of any size, easy to use, complete and 100% Open Source. This repository contains the source for all the packages of Tryton. Setup ===== It is recommended to isolate the development within a Python `virtual environment <https://docs.python.org/tutorial/venv.html>`_. From the root directory of the repository run: .. code-block:: console .hooks/update_requirements .hooks/link_modules .. warning:: The process of updating requirements files may take some time. Install the dependencies with: .. code-block:: console pip install -e trytond -e tryton -e proteus -r requirements.txt -r requirements-dev.txt Automate ======== To automate the process, add the following lines to the ``[hooks]`` section of the ``.hg/hgrc``: .. code-block:: ini [hooks] update.modules = .hooks/link_modules update.requirements = .hooks/update_requirements On ``hg update``, the first hook will automatically create symlinks for modules and the second hook will automatically generate requirements files. Submit Change ============= For information about how to submit change, please read on and follow the `guidelines <https://www.tryton.org/develop>`_.