On Fri, Feb 20, 2015, at 11:28 AM, Mike Bayer wrote: > > > Doug Hellmann <d...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev