Normally, this should work by simply replacing jackrabbit jars.
Bogdan
Cédric Joyau wrote:
Hi lads,
Jackrabbit's perfs have been improved thanks to the bundle managers
included in version 1.3, but the current version of Nuxeo Core
supports Jackrabbit 1.2, so when do you plan to support the new one ?
I'll do some benchs when it's available ;)
--
Cédric
On 6/10/07, *Cédric Joyau* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I agree with you Florent, since Jackrabbit sessions are already
optimized there's no need to do some pooling on Nuxeo side. My
concern is that Jackrabbit maintains a single connection to the
database on its side, and that's where we could have a bottleneck.
I'll test some BundlePersistenceManagers and see what comes up.
Cédric
On 6/9/07, *Florent Guillaume* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
You're both talking of pooling at different levels.
Cédric talks about pooling inside Jackrabbit of the jdbc
connection
it maintains to its underlying database. This is Jackrabbit's
internal sauce, and its responsibility.
Bogdan talks about pooling JCR session at the Nuxeo level.
Actually I doubt this latter pooling is needed. One needs
pooling when:
- creating a new session is expensive -- but it's not for
Jackrabbit,
- reusing an old session gives the benefit of reusing caches
-- but
the caches in Jackrabbit are still maximally shared by all
sessions
when possible anyway, there are internal Jackrabbit datastructures
for that (see SharedItemStateManager).
So unless someone proves to me that session pooling is needed, I'm
not going to lose sleep over this :)
Florent
On 8 Jun 2007, at 17:49, Cédric Joyau wrote:
> JackRabbit doesn't handle pooling at its level, at least not the
> SimpleDbPersistenceManager. Discussion takes place over here :
> http://www.mail-archive.com/[EMAIL PROTECTED]/
> msg04431.html
>
> I'm not an expert, but do you think it's possible to use an
> existing pooling system and make it work with JackRabbit in
Nuxeo ?
> (reusing the JBoss one for instance, or using the commons-dbcp
> package from the jakarta project). I'll have a deeper look into
> this next week.
>
> > Any volunteer to test if pooling on jackrabbit session is
> improving perfs.? :)
>
> Well, I am :)
>
> Cedric
>
>
> On 6/8/07, Bogdan Stefanescu < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
> Connections are handled by JBoss JCA implementation.
> Nuxeo provides a resource adapter for the underlying repository
> (jackrabbit) that is registered in JBoss.
> Then jboss is using a pool of managed connection and also
ensure the
> repository resource is enlisted on the current transaction.
> In fact if I remember well physical connections to jackrabbit
> (jackrabbit sessions) are closed when a managed connection
> is reused from the pool. So practically there is a JCR
session per
> request which is closed after the request ends.
>
> So at nuxeo core level we don't use pooling.
> I am not sure if Jackrabbit do some pooling at its level. But I
> think it
> should optimize connections to underlying
> databases (or other storages)
>
> Any volunteer to test if pooling on jackrabbit session is
improving
> perfs.? :)
>
> Bogdan
>
>
> Cédric Joyau wrote:
> > Hi,
> >
> > I'd like to know how Nuxeo handles connections to
datasources and
> the
> > content repository ... is it a single connection for each
one or
> it is
> > possible to set up a connection pool ? Do you plan to do some
> > performance tracking on this ?
> >
> > Cheers,
> > Cédric
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
