[openstack-dev] [all] [oslo] Proposed database connectivity patterns

Mike Bayer mbayer at redhat.com
Fri Oct 10 15:41:16 UTC 2014


On Oct 10, 2014, at 6:13 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Signed PGP part
> On 09/10/14 21:29, Mike Bayer wrote:
> > So so far, everyone seems really positive and psyched about the
> > proposal.
> >
> > It looks like providing some options for how to use would be best,
> > that is provide decorators and context managers.
> >
> > Now the thing with the context manager, it can be as I stated:
> >
> > with sql.reader() as session:
> >
> > or we can even have that accept the “context”:
> >
> > with sql.reader(context) as session:
> >
> > The latter again avoids having to use thread locals.
> >
> > But can I get a feel for how comfortable we are with using thread
> > local storage to implement this feature?   I had anticipated people
> > wouldn’t like it because it’s kind of a “global” object, even
> > though it will be hidden behind this facade (of course CONF is
> > global as is sys.modules, and I think it is fine).     If I just
> > use a tlocal, this whole thing is pretty simple.
> 
> Won't the approach conflict with eventlet consumers that for some
> reason do not patch thread module, or do not patch it early enough? I
> guess in that case we may end up with mixed contexts.

I’ve been asking a lot about “hey are people cool with thread locals?” and have been waiting for what the concerns are.    

Since I wrote that email I’ve shifted, and I’ve been considering only:

@sql.reader
def my_api_method(context, …):
   context.session

def my_api_method(context, …):
  with sql.using_reader(context) as session:
    session , context.session

because in fact, if you *want* to use a thread local context, you can, explicitly with the above:

GLOBAL_CONTEXT = threading.local()

def my_api_method(…):
  with sql.using_reader(GLOBAL_CONTEXT) as session:
    session 

I like that one the best.  But again, Keystone folks would need to accept this explicitness.

The challenge on my end is not technical in any way.  It’s getting every project to agree on a single approach and not getting bogged down with idealistics (like, “let’s build a dependency injection framework!”).    Because this “everyone does it their own way” thing is crazy and has to stop.







More information about the OpenStack-dev mailing list