From: Francis Cianfrocca Date: 2006-11-06T22:26:18+09:00 Subject: Re: Net::LDAP connection semantics problem and nested blocks. On 11/5/06, Luke Daley wrote: > > On 01/11/2006, at 3:11 PM, Francis Cianfrocca wrote: > > > What LDAP operations are you performing here? > > In the particular case when I hit the problem, it was an attribute > level modify operation. I realise my original post was extremely hard > to decipher, I was rather pressed for time when I put it together. > > I have a script which consumes 'jobs' off a queue. One of the jobs > may be to update the name details for a particular user in domain a, > the next to update the phone number in domain b. Therefore opening > one connection using open() is not an option. > In regard to the design decision in the library: it's essential to be able to document and depend on the network behavior of Net::LDAP. That's more important than that it obey one semantics or another. The decision came from years of experience with the various Michigan-derived C implementations, which try to wrap the connection away from the API, which in turn leads to bizarre, hard-to-find bugs. Why don't you put your queue consumer inside the Net::LDAP#open block and let it run as long as it wants to? You can put multiple #open calls on different threads if you have to connect to more than one LDAP server. The only thing I would be concerned about is that the LDAP servers may time out your connections, but you can manage that by putting your own timeout in your Queue-query.