Hi Shanto,
When a client is no longer needed, it should be returned to the pool by calling release on the pool entry. If you want to make sure that this client is no longer used, you should call delete on the pool entry. If neither of these steps are taken, the jcoclient service keeps track of the pool entry. This means that such a pool entry still participates in the connection limit. This can prevent other calls of getJCOClientPoolEntry from obtaining a pool entry when the limit is reached.
Important: Under no circumstances may release be called on a pool entry when the client in question is still being used or referenced. Releasing such a pool entry makes the client available for further use in different threads, resulting in system errors because a client may not be used in different threads at the same time.
Note that calling disconnect or connect on a client has no influence on the number of connections currently counted by the connection limit. The granularity with which a connection is counted is defined by the pool entry. This means that a connection is counted from the time the pool entry was obtained using getJCOClientPoolEntry until this pool entry is released or deleted by the user or by the jcoclient service (in case of HTTP session timeout) or finalized by the Java VM. With regards to the connection limit, what is done with the client between these two times is of no importance.
Special attention must be paid to pool entries that are stored for use in several requests, Proper synchronization must be implemented here to prevent use of a client in different threads, while still keeping parallel execution where possible.
When you obtain a client to work with a JCo repository, its pool entry should not be released while the repository is being accessed.
regards
Sreedhar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.