[SSSD] LDAP connection tracking, sharing and fail-over retry framework

Stephen Gallagher sgallagh at redhat.com
Wed Jul 7 12:43:41 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Sounds good. I just want a confirmation that it is in line with tevent 
> coding style to pass pointer to higher level state (hbac_ctx) into 
> sub-operations (hbac_get_host_info_send() and others).

It's fine to percolate it down where necessary, provided that the
functions it's going into must ALWAYS be a descendent. (E.g. it's okay
to pass it into helper requests, but passing it into sdap_generic_send()
would be a mistake)

>> I think this would be the better way to go. It will avoid the potential
>> race condition.
>>
>>    
> I will do it today.

Great, thanks!


> 
>  From my point of view we should go even further and not to store 
> intermediate stage results to sysdb until all data is received from LDAP 
> server. Otherwise we could use inconsistent data in OFFLINE mode.

Can you point me at a case where we're saving data before the LDAP
server is complete? That sounds like a bug. I agree that we shouldn't be
writing the ldb_transaction until we have everything.

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

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkw0dn0ACgkQeiVVYja6o6MXagCfUCpBfEkycR1MeRBS+YZWUDwB
4W0An14uYYcp65zNF10r4fHSaxMEUdVn
=RnrR
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list