Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1121796

Summary:	potential race condition on dialect init in SQLAlchemy 0.8.4
Product:	Red Hat OpenStack	Reporter:	Michael Bayer <mbayer>
Component:	python-sqlalchemy	Assignee:	Michael Bayer <mbayer>
Status:	CLOSED ERRATA	QA Contact:	Ami Jeain <ajeain>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.0 (RHEL 6)	CC:	apevec, dnavale, lhh, mbayer, nbarcet, sclewis, sgordon, yeylon
Target Milestone:	z4	Keywords:	ZStream
Target Release:	5.0 (RHEL 7)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:
Clones:	1198773 (view as bug list)		Environment:
Last Closed:	2015-04-16 14:37:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1198773

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