Hi Alex,
> Andrea, I must confess that I haven't got the time too fully look
> through your code. Moreover it is not immediately clear how it gets
> called, as the class is offering only a get operation and not a
> release as normal pools.
This is the code used to call the pool:
...
RepositoryManager rm = new RepositoryManager();
Session session = rm.getSession(this.getHttpsession());
...
and then in RepositoryManager:
...
if (user.getJcrUsername().equalsIgnoreCase("ANONYMOUS")) {
session =
JcrSessionPool.getConnectionPool().getSession(workspace, httpsession);
}
...
and the logout method (effectively never done because of anonymous user)
...
JcrSessionPool.getConnectionPool().sessionLogout(session, getHttpsession());
...
in this case, if you are an admin, logout is effective because of session is
dedicated
and not taken by the pool, but singular in this way:
...
repository = (Repository)context.lookup("jcr/repo");
SimpleCredentials cred = new SimpleCredentials(username,
password.toCharArray());
session = repository.login(cred, workspace);
return session;
...
> But, if you are invoking this code on each HTTP request, then I would
> say that you really have a big bottleneck in your app and you should
> try to get rid of it (synchronization at the level of your pool,
> synchronization at the level of collections). My whole heartly advise
> would be to look into an existing pooling solution (even if a generic
> one) and try to use it. Without any intentions to criticize your code,
> most probably an existing solution would have already been passing
> through testing and different scenario usages that are making it a bit
> more stable and reliable than your home made pool (I really hope you
> are not getting this the wrong way).
No problem at all Alex. I have to say that I tested the app with load
testers and it worked well.
And.. during tests, I have no locks at all... It happens randomly on a
clustered version of the app
after several hours of use. Talking about using another pool, I can stay
with you. But the point is
to understand why this pool is locking. No error are catched in the class i
sent, no errors at all...
No new sessions are created in getSession method except when
sessionPoolCleaner is called.
So I can say that it could happen also with others pools?
Version used is JR 1.3.1 patched with JCR-905 patch for clustered
enviroments.
Could be a problem linked to wait locks? No waitTimeout is defined in JCA
connector configuration, so...
Or could be a deadlock problem related to itemCache, JCR-862 for example?
Do you think that let synchronized only the class and not method could be
correct and more fast?
Another point, workspaces are fully working accessed with
Does anyone can help or address me to a solution or a real-life (code)
solution?
Thanks a lot.
BR.
Andrea -
> bests,
> ./alex
--
View this message in context:
http://www.nabble.com/Shared-session-pool-tp14486499p14729813.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
