In the OpenLDAP, the incoming requests are first inserted in a list and then assigned to the work threads. Take a scenario as follow, there are T1,T2,T3,...Tn requests in order, T1 2 is a "modify request", and T3 is a "search request".If these request are serially handled one by one, then T3 will get the updated info by T2. But if the requests are assigned to work threads and handled concurrently, will the following case happen?
T2 and T3 are assigned to Thread A and Thread B, but Thread B is scheduled before A. So T2 is handled after T3. And later request, T3 will never get the newly updated info?
If this case can never happend, how does OpenLDAP guarantee the incoming requests are handled in order even if the work threads are scheduled randomly?
Thanks a lot:)
石斌(Seuler.shi) wrote:
In the OpenLDAP, the incoming requests are first inserted in a list and then assigned to the work threads. Take a scenario as follow, there are T1,T2,T3,...Tn requests in order, T1 2 is a "modify request", and T3 is a "search request".If these request are serially handled one by one, then T3 will get the updated info by T2. But if the requests are assigned to work threads and handled concurrently, will the following case happen?
T2 and T3 are assigned to Thread A and Thread B, but Thread B is scheduled before A. So T2 is handled after T3. And later request, T3 will never get the newly updated info?
If this case can never happend, how does OpenLDAP guarantee the incoming requests are handled in order even if the work threads are scheduled randomly?
In general there are no guarantees. You can use the PostRead control if you need to retrieve the content of an entry immediately after modifying it.