Open Stack

Doug Hellmann <doug at doughellmann.com> wrote:

> 
> 
> 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.

I’m just looking for, “a log line”.  So the next time a “SQLAlchemy is not loading my result correctly” bug gets sent to me, I can look in their logs, see this note, and know why it’s happening, rather than having to dig into all the querying code and making sure their mappings are correct, trying to run their bug under devstack, and everything else.

I’m trying to use software to give me information to make my life easier.   What a crazy idea !