[Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible.

[Rob Crittenden]

Pavel Zuna wrote:
> Jason Gerard DeRose wrote:
>> On Tue, 2010-01-05 at 14:10 +0100, Pavel Zuna wrote:
>>> The backend.Connectible base class was designed, so that only one 
>>> instance of each subclass is used at a time. Connectible generates a 
>>> Connection object for each thread and stores it in thread-local 
>>> storage (context). Subclasses access this object through the 
>>> Connectible.conn property.
>>>
>>> This is a good thing, because one instance of the class can be shared 
>>> by all threads and each thread has its own connection. Unfortunately, 
>>> this is also a limitation. If a thread needs a second connection (to 
>>> a different host for example) - it can't do it. Not even by creating 
>>> a new instance of the Connectible subclass.
>>>
>>> Ok, let's move from theory to practice:
>>>
>>> The LDAP backend is currently only used by the Executioner backend, 
>>> so that plugins can connect to the IPA DS.
>>>
>>> In the migration plugin, we need a second connection to the DS we're 
>>> migrating from. The last version had to use low level python-ldap 
>>> calls to achieve this.
>>>
>>> In the installer we're still using legacy code from v1. Using ldap2 
>>> would be simpler and we could drop ~1000 lines code. (I already 
>>> started rewriting a few parts to see if it would work.)
>>>
>>> Proposed solution:
>>>
>>> Make it possible to create unshared instances of Connectible subclasses.
>>>
>>> This would be achieved by passing shared_instance=False (couldn't 
>>> come up with a better name) to the object constructor explicitly. 
>>> Normally, Connection objects are stored in thread-local storage under 
>>> the subclass name (e.g. "ldap2"). Unshared instances would store 
>>> their Connection objects under subclass name + unique instances ID 
>>> (e.g. "ldap2_218adsfka7").
>>>
>>> This is the only solution I could come up with, that doesn't involve 
>>> breaking a lot of stuff - it just adds a new way of using the code we 
>>> already have.
>>>
>>> The attached patches show how it would be done.
>>>
>>> Pavel
>>
>> I'm fine with this approach as the solution you propose is quite
>> unobtrusive.  Is this the final patch then, or will you make further
>> changes or bundle it with another patch?
>>
> Yeah, this is the final patch. Upcoming patches will depend on it.
> 
> Pavel
> 

pushed to master