This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

The problem with this bug is that it's random - you'll note the logger.info("blip") so I can monitor the iterations of the loop. The number of blips output is entirely random! I've read a few posts on this subject and some have suggested connection pooling may be a problem, and hence I'm wondering if LdapTemplate can ever do the job properly given it closes the context after the search has been executed.

Does anyone have a concrete example of this functionality working for thousands of records in the LDAP?

The problem is most likely related to the closed context. In the upcoming release (1.3-rc1 is due in a couple of days) we provide a SingleContextSource implementation, which will make sure that the actual target connection is never closed.

Comment

I did try and override the search method in LdapTemplate and comment out the calls to close the context but this still failed. Can you tell me where to find 1.3rc1 (or some recent build) and I'll happily try out your suggestion? Perhaps you can also post some example config for this new context source?

Thanks,

John

Comment

On further consideration, do we not need a search mechanism that specifically does not call context close? The lifetime of the connection needs to be guaranteed over the multiple calls to ldapTemplate.search.

Comment

The explicit call to close is imperative in LdapTemplate to prevent connection leaks - there's really no way around that.

What the SingleContextSource does is that it creates a proxy around the target DirContext instance which ignores any calls to close, so in effect close will actually never be called on the target DirContext.

You can accomplish the same behavior in 1.2.1 using the built-in client-side transaction support: declare a ContextSourceTransactionManager, create TransactionAwareContextSourceProxy around your ContextSource, and then perform your loop within a transaction boundary. That will make sure the same actual target connection (DirContext) will be used throughout the entire transaction. Check out the reference docs for more information on how to configure this.

If you want to try out the SingleContextSource you can get the latest code from svn trunk:

Comment

I've implemented the transaction manager but it still fails - in fact, the LDAP query fails on the second attrempt, without fail. This is actually worse than not using the transaction manager as it did at least do a few iterations before failing! Here's the exception:

Comment

I honestly don't know what's going wrong here. LDAP error 12 means "Unavailable Critical Extension Requested". I have so far been unable to reproduce. Could you debug and set a breakpoint in AbstractRequestControlDirContextProcessor#preProce ss(). It might be interesting to see the contents of the newControls array at the end the second time you perform the search.