[
https://issues.apache.org/jira/browse/FC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198567#comment-14198567
]
Emmanuel Lecharny commented on FC-42:
-------------------------------------
Th ebool can contain bound connections, but there are two critical things :
- first of all, as anyone can switch from a standard LDAP connection to a
secure LDAP connection through the use of a StartTLS extended operation, we
must reset the connection when we put it back to the pool. That mean rebind it
(which does not reset the protocol layer, hopefully)
- and second, the validation is also a must have, as we can't simply consider
that the connection is valid when we pull it from the pool.
Now, I think there is room for improvement in both areas :
- when a connection is closed, either by the user, or by an error leading to a
disconnection, or through a timeout, then the 'connected' flag is switched to
false, so we can detect this state in the validation phase.
- We probably can define a pool that does not do a re-bind when the connection
is pushed back in the pool. That would b a weaker pool, but as soon as we
control what we do, that should be ok.
Although I still thinks we should reuse teh same connection across all a
Manager operation.
> Avoid pulling a new connection from the LDAP connection pool
> ------------------------------------------------------------
>
> Key: FC-42
> URL: https://issues.apache.org/jira/browse/FC-42
> Project: FORTRESS-CORE
> Issue Type: Improvement
> Affects Versions: 1.0.0-RC39
> Reporter: Emmanuel Lecharny
> Fix For: 1.0.0-RC40
>
>
> Atm, everytime we want to send a request to the LDAP server, we are acquiring
> a connection from the LDAP pool of connections. It's quite expensive, as each
> connection has to be rebind everytime we push it back, and we do a validation
> (thus a read) everytime we ask back a connection.
> If we were to pass the connection we picked in the first call to all the
> methods, we would save those costly Bind and check.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
