Repository Session pools

[alexeyg]

I am having a problem creating a JCR session pool.  Any suggestions are appreciated.

I set SimpleCreds and Repository for my Pool, then do lazy init for Repository Sessions. (using tomcat)

The problem comes up in this scenario:

1) Request A comes in, A is handled by thread P.  Session Z is created (Z is associated with P).

2) Request A is finished, session Z remains open in pool

3) Request B comes in, takes up session Z.

4) Request C comes in, is handled by thread P.  Session Z is busy - need to create new session.  Thread P attempts to create a session - Exception! (there is a session Z associated with thread P already)

What are my options?  I was thinking:

- always start the Session from a new thread (but what if a new thread matches older thread?)
- check Alfresco source code, see what Thread is remembered by, keep a mapping in my app to make sure no duplicates are started.
- keep 1 session for all "read" operations, only give out root node.

The last option seems most attractive… but are may be possible concurrency issues with giving out root nodes from one session for all "read" operations… right? 

Thank you!

[davidc]

JCR session login is not heavy.  The Alfresco JCR facade is very thin and relies upon level 1 and level 2 caching of the underlying Alfresco repository services - hardly anything is cached against the JCR session itself.

Therefore, you might want to consider retrieving a new session for each thread.  This will give each thread its own transaction and is thread safe.  If you want to throttle usage, throttle the number of concurrent threads.

[alexeyg]

Thanks for your reply!

Would you actually recommend starting a new session for each thread, or is it more of a convenience thing?

We have multiple independent repository requests generated from each HTTP request - session pool came about because I was paranoid multiple log-ins per single request.

Since posting I got it working by having the session pool start a new session from another thread.  It seems to work really well…  i will keep it that way unless you see possible problems with that setup…

I am still getting "A valid SecureContext was not provided in the RequestContext" exceptions on session.getRootNode() from time to time… but refreshing the session by loggin in again takes care of that…