On 07/08/2010 09:21 PM, Simo Sorce wrote:
On Wed, 07 Jul 2010 08:43:41 -0400
Stephen Gallagher<sgallagh(a)redhat.com> wrote:
>> Another reason to have sdap_id_op as separate tear is caching
>> strategy: it would ineffective if LDAP connection was dropped in
>> the middle of multi-stage operation, that could be the case if
>> connection usage tracking is done within sdap_generic_send. Using
>> higher level tear ensures that connection is available through
>> complete operation, not just within single stage.
>>
> Yeah, I think I agree with you here.
>
Sorry I don't see how it differs here.
If sdap_generic_send() is always restarted when the connection drops
you have exactly the same effect. If it can't be restarted you again
have the same effect, the upper level operation will fail with an error.
What am I missing here ?
Let's consider IPA HBAC processing, which requires 3 LDAP requests:
- request for HBAC hosts
- request for HBAC rules
- request for HABC services
If we do reconnect logic within sdap_generic_send, than after request
for HBAC hosts is completed LDAP connection is released and could be
dropped, as sdap_generic_send has no idea about second (HBAC rules) and
third (HBAC services) requests that still needs to be processed.
Eugene