IfsLibrarySession

Question

Has anyone seen any performance loss when multi threading an IfsLibrarySession object? I'm developing an http web service that will be used by hundreds of clients for manipulating documents in Ifs. I had planned on using only one IfsLibrarySession for all requests, however, my load testing has determined that performance suffers when using only one session. Therefore, I have developed a pool manager very similar to database connection pooling. Has anyone seen these performance problems when using just one IfsLibrarySession??? Any comments would be greatly appreciated. Thanks in advance.
Louis

Answer 1

Here's some info straight from the developers:
LibrarySession is threadsafe. But there are some things an application developer should be aware of.
1) Some API-exposed state is bound to LibrarySessions. The most important is the transaction state. When using explict transaction demarcation (e.g. the beginTransaction, completeTransaction, abortTransaction methods), it is the application developer's responsibility to ensure that threads operating on a particular session don't inadvertantly "interleave" transactions. Another, but less ominous example, is default folder sort specification (the setDefaultFolderSortSpecification and getDefaultFolderSortSpecification methods).
2) To make LibrarySession threadsafe, iFS uses Java synchronization everytime database access is necessary, and at certain other points. (Because of caching and other factors, not every call to an iFS API results in database access.) So even though many threads can operate against a single LibrarySession, they will be "single-tracked" at certain points.
For these reasons, and others having to do with access control, we'd discourage using a single LibrarySession to service all requests. If the access control issue isn't a factor (for example, providing "guest" access), consider using a pool of LibrarySessions.
Separate LibrarySession instances running in their own threads will only block one another when:
1. While waiting on a database connection from the connection pool
2. While waiting for another session to complete its transaction because of some database lock (e.g. if two sessions were attempting to update the same object)
- A possible case of this involving the same user is in updating read indication - i.e. if two LSs were reading the same documents in transactions that were not closed.
- There may be some other situations, but they're more obscure; like if two sessions have both decided that it was time to perform "piggyback" operations (e.g. purging the caches) at the same time; in this case one thread will block while the other completes the task.
I can't think of anything special about the "same user" condition, other than the read indication one listed above.