You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Jeorjos Valotasios <va...@gloman.gr> on 2008/01/30 14:49:11 UTC

Using jackrabbit

Hello,
I would be interesting in using a jcr instead of a relational db for a
project that whould actually be a very simple content management system. My
question is if someone has some kind of benchmarking. What would be the best
of the persistence managers that are available. I tried it a little bit but
I found out that there is no support for datasource and this means that
connection pooling is not possible (at least not out of the box). As I have
not seen a single database based application that does not uses connection
pooling I am a little bit curious about how well can jackrabbit perform with
a database persistence manager without connection pooling.

The "cms" I intend to build is very simple but must handle a lot of traffic.
Our current system handles about 15000 hits per minute with most of them
being a simple record update.

-- 
Valotassios Jeoryos

GLOMAN S.A.
2 Papada str,
Athens, GR 115 25

T: +30 210 6985700
E: valotas@gloman.gr

Re: Using jackrabbit

Posted by Jeorjos Valotasios <va...@gloman.gr>.
On 1/30/08, Esteban Franqueiro <es...@bea.com> wrote:
>
> Hi.
>
> > I would be interesting in using a jcr instead of a relational db for a
> > project that whould actually be a very simple content management system.
> My
> > question is if someone has some kind of benchmarking. What would be the
> best
> > of the persistence managers that are available. I tried it a little bit
> but
> > I found out that there is no support for datasource and this means that
> > connection pooling is not possible (at least not out of the box). As I
> have
> > not seen a single database based application that does not uses
> connection
> > pooling I am a little bit curious about how well can jackrabbit perform
> with
> > a database persistence manager without connection pooling.
>
> Indeed, it would be interesting to know, since there's an ongoing
> discussion regarding the merits of
> using pooling in Jackrabbit.
> If you have some results, please present them.


Well I was hoping that someone  would have some results to present!

If you are planing to use it, the DbDataStore does have a simple poolong
> mechanism. It would be very
> interesting to know how it scales.
>

Well I first try to find someone who had some experience and would like to
share them in order not to start something from scratch that would not have
the expected result in performance.


Regards,
>
Esteban Franqueiro
> esteban.franqueiro@bea.com




-- 
Valotassios Jeoryos

Re: Using jackrabbit

Posted by Esteban Franqueiro <es...@bea.com>.
Hi.

> I would be interesting in using a jcr instead of a relational db for a
> project that whould actually be a very simple content management system. My
> question is if someone has some kind of benchmarking. What would be the best
> of the persistence managers that are available. I tried it a little bit but
> I found out that there is no support for datasource and this means that
> connection pooling is not possible (at least not out of the box). As I have
> not seen a single database based application that does not uses connection
> pooling I am a little bit curious about how well can jackrabbit perform with
> a database persistence manager without connection pooling.

Indeed, it would be interesting to know, since there's an ongoing discussion regarding the merits of 
using pooling in Jackrabbit.
If you have some results, please present them.
If you are planing to use it, the DbDataStore does have a simple poolong mechanism. It would be very 
interesting to know how it scales.
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.