Multiple requests on single connection with synchronous API
A Java-based LDAP API
Brought to you by:
dirmgr,
kennethleo
Menu
▾
▴
#1 Multiple requests on single connection with synchronous API
Hi
My application is made of multiple threads ([100..500] ) that interwork with an LDAP server through a limited number of connections (40);
I am using the LdapconnectionPool and synchronous API
Initially setUseSynchronousMode of class LDAPConnectionOptions was true so the observed behavior was normal: a other request was sent to the server only when the previous answer was received; But after changing the setting ( setUseSynchronousMode = false), i didn't get what i expected;
I 'd like to know whether sending multiple request from multiple thread on a single connection of a pool is supported and if yes could you tell me the right settings or asynchronous API is mandatory to send traffic
Thanks for your support
You should not use pooled connections for asynchronous operations (whether that connection is shared by multiple threads or ). The connection pool implementation explicitly assumes that if a connection is in the pool, then it is not in use by anything else, and an attempt to use that connection in some other way may cause problems. It will definitely interfere with things like health checking and connection expiration.
It would be possible to obtain a connection from the pool and use it to perform asynchronous operations (either by sharing that connection across multiple threads or by using one of the async* methods that it provides), but if you do that, then you must ensure that the connection is not operating in synchronous mode, and you must ensure that all operations initiated on the connection are completed or abandoned before releasing it back to the pool.
If your application is such that there will never be more than 40 concurrent operations in progress, then I'd recommend not using asynchronous operations at all and just relying on the connection pool to handle things. In the event that things get really busy and there is an attempt to use more than 40 concurrent connections, you can configure the pool so that any additional operation requests will need to wait for a connection to become available (optionally specifying a timeout, and optionally creating a new connection if the timeout is encountered, or you don't want to wait at all).
If you will have more concurrent operations than connections, then you will have to use asynchronous operations, but that is tricky with pooled connections. You might need to create your own kind of pooling mechanism to deal with that rather than using the one provided with the server. In that case, you'll have to be aware that closing a connection could potentially impact active operations on other threads.
Thanks for feedback
Yes, when i use a pool, i check out the connection from the pool before using it ;
Yes, I have much more threads than connexion and I have to interwork with a ldap server having a high latency and supporting a limited number of connections
My key question was to know whether it is possible to share a connection between multiple threads and use synchronous API;
In other words, I want to double confirm if I absolutely need to modify my current implementation based on synchronous API and pool (getConnection, search operation, release connection) and switch to asynchronous API;
Every thread indeed needs to wait for the response but due to big latency and low number of connection , I need to use many threads and send requests (1 or 2 per tread ) on a limited number of connexion to reach capacity requirements
Thanks for your support
As long as a connection is checked out of the pool, then you can treat it basically the same as a non-pooled connection.
If you want to use that connection simultaneously by multiple threads, then you can do that as long as the connection is not configured to use synchronous mode (and it is not by default). You can use the asynchronous API, but you don't have to.
You will also want to make sure that you don't do something to that connection with one thread that might adversely impact or be incompatible with operations that might try to use the same connection at the same time from other threads (for example, if you perform a bind on a connection, then it will change the identity that will be used for access control evaluation, and because of LDAP constraints may actually interrupt other operations in progress on that connection).
When you check the connection back into the pool, you must make sure that no other threads are still trying to use it. You should also make sure that it's in an acceptable state to be used if it's checked out again. If you've done something to change the state of the connection in an unacceptable way, then you should return the connection as defunct and it will cause that connection to be closed and another re-established to take its place.