On 11/5/06, Luke Daley <ld / ldaley.com> 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.