Open Stack

On Fri, Feb 20, 2015, at 11:28 AM, Mike Bayer wrote:
> 
> 
> Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > 
> > And I don't think we want the database library doing anything with this
> > case at all. Recovery code is tricky, and often prevents valid use cases
> > (perhaps the parent *meant* for the child to reuse the open connection
> > and isn't going to continue using it so there won't be a conflict).
> > 
> > The bug here is in the way the application, using Oslo's service module,
> > is forking. We should fix the service module to make it possible to fork
> > correctly, and to have that be the default behavior. The db library
> > shouldn't be concerned with whether or not it's in a forked process --
> > that's not its job.
> 
> OK.  But should the DB library at least *check* that this condition is
> present?  Because, it saves a ton of time vs. trying to understand the
> unpredictable and subtle race conditions which occur if it is not
> checked.

I really don't think that's the right place to deal with the situation,
either with a fix or a check or whatever. The race today happened to be
in the database code, but it could easily have been in the messaging
library or something else that shares a connection to a remote service.

Doug

> 
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev