Ivan Sagalaev wrote: > JP wrote: > > Looking back over the multi-db branch today, I realized that it seems > > to be duplicating the thread locality of connections. The connection > > management classes in multi-db django.db manage all connections as > > thread local, and the DatabaseWrapper classes in the backends are all > > subclasses of local. > > > > I may be missing something, but I think the latter locality can be > > safely removed in multi-db. > > I didn't look how exactly multi-db branch manages connection so my > question may be dumb, sorry. If you intend remove the inheritance of > DatabaseWrapper from locals does it mean that when using single DB > DatabaseWrappers will be shared between threads?
Not a dumb question at all. I'll try to explain better by contrasting how multi-db handles connections with how connections are kept thread local in trunk. In trunk, django.db.connection is a DatabaseWrapper instance from some backend. DatabaseWrappers all subclass local, so their attributes are thread local, including the self.connection attribute that is the actual db connection. When you try to get a cursor for the first time in a thread, a connection is made based on the current settings and stored in the local attribute. In multi-db, all connections (including the default that you can access as django.db.connection) are managed through a LazyConnectionManager instance, which keeps a thread-local map of connection name to DatabaseWrapper, and is generally accessed through django.db.connections, like: from django.db import connections, _default, connection foo = connections['foo'] connection is connections[_default] # True When a connection is first accessed in a thread, the connection is established based on the appropriate settings (either defaults or a named connection in OTHER_DATABASES) and a DatabaseWrapper is cached in thread local storage. django.db.connection is a lazy proxy that looks up connections[_default] when accessed for the first time in a thread, and caches the result of that call in another local (for efficiency, otherwise we'd be executing a lambda: every time we touched the connection, which would be bad). So each individual connection instance doesn't need to be a local anymore, because it can only be accessed by a lookup into a local, no matter how you get at it. > > DatabaseWrappers don't have to be local > > because each instance can only be accessed in a particular thread > > anyway. > > I don't exactly understand this bit also. Does it mean that each thread > gets its own instance or that threads can access some (shared) instance? Each thread gets its own DatabaseWrapper instance, rather than one DatabaseWrapper (with local attributes) being shared among all threads. Does that make things more clear? JP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
