Bug 1121796 - potential race condition on dialect init in SQLAlchemy 0.8.4
Summary: potential race condition on dialect init in SQLAlchemy 0.8.4
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-sqlalchemy
Version: 5.0 (RHEL 6)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z4
: 5.0 (RHEL 7)
Assignee: Michael Bayer
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks: 1198773
TreeView+ depends on / blocked
 
Reported: 2014-07-21 21:57 UTC by Michael Bayer
Modified: 2023-02-22 23:02 UTC (History)
8 users (show)

Fixed In Version: 0.8.4-2.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, an improvement to the connection pool such that new connections could be made concurrently, made it so that the 'init on first connect' routine of a SQLAlchemy dialect would not have been completed if concurrent routines proceeded at the same time. As a result, when a SQLAlchemy engine was first used, operations which relied on the state acquired during initial startup could fail, as this information would not have been completed. To resolve this issue, with this update, 'mutexing' was added to the event system which handles the initial dialect startup phase, so that connection attempts are again serialized, but only when the engine first starts up.
Clone Of:
: 1198773 (view as bug list)
Environment:
Last Closed: 2015-04-16 14:37:13 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0825 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Bug Fix and Enhancement Advisory 2015-04-16 18:28:14 UTC

Description Michael Bayer 2014-07-21 21:57:59 UTC 
Description of problem:

A critical fix was issued in SQLAlchemy 0.8.5 regarding dialect initialization, first introduced as a regression in 0.8.4 where the process of determining database version and attributes upon first connect is no longer synchronized, leading to initialization failures for concurrent connections that skip the initialization step.  


How reproducible:

start any two database connections from a new engine simultaneously, the second connection may not function correctly until the first connection completes its queries.


Steps to Reproduce:

1. the test case at https://bitbucket.org/zzzeek/sqlalchemy/commits/4ac0558e11497553a4d0460111d8fbd667396a7f#Ltest/engine/test_pool.pyT498 illustrates the race condition.

SQLAlchemy bug: https://bitbucket.org/zzzeek/sqlalchemy/issue/2964.  Note there are two separate git revisions to implement the fix fully.
Comment 4 Ami Jeain 2015-03-30 12:29:17 UTC 
verified:
ran the code from: https://bitbucket.org/zzzeek/sqlalchemy/commits/4ac0558e11497553a4d0460111d8fbd667396a7f#Ltest/engine/test_pool.py
Comment 6 errata-xmlrpc 2015-04-16 14:37:13 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0825.html
Note You need to log in before you can comment on or make changes to this bug.