On Jan 6, 2010, at 5:26 PM, Felix Meschberger <[email protected]>
wrote:
Hi,
On 06.01.2010 23:20, Justin Edelson wrote:
+1
Session pooling is part of Jackrabbit 2 (which is where it belongs)
anyway. IIRC, you removed it in your JR 2 branch.
I actually removed it in that branch exactly for the reasons outlined
below ;-)
And I now realize that it was db connection pooling which was added
in JR 2.
Justin
Regards
Felix
On Jan 6, 2010, at 5:11 PM, Felix Meschberger <[email protected]>
wrote:
Hi all,
Today I stumbled upon a potential problem with the JCR Session
Pooling
we have in the JCR Base bundle.
Some time ago, we disabled session pooling by default. Only today I
actually set this default for the Embedded Jackrabbit bundle (see
SLING-1272).
The problems with session pooling are manyfold, some of the issues
are:
* Only works with SimpleCredentials authentication
* Wrong level of abstraction: such optimizations are the task of the
repository implementation and not of the user
* Cleanup of the session for reuse is brittle and timeconsuming
(due to a JCR search to ensure unlocking transient locks)
* Little to no gain in performance (in fact performance is even
lower than using plain Jackrabbit Sessions.
The only real use of the current session pooling, we might
discuss, is
the optional limitation of concurrent requests per user. But even
this
feature is disabled by default.
For these reasons, I think we should remove the Session Pooling
support
from the JCR base bundle.
WDYT ?
Regards
Felix
