jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: Thoughts on database persistence
Date Sat, 18 Mar 2006 20:43:29 GMT
Hi to all,

 more thoughts on database persistence ...

  It seems having a jdbc based persistence manager as the default
implementation misleads users, new and not so new users often think
that jackrabbit will benefit from rdbms features and analyze
jackrabbit internals taking into account j2ee best practices.

  Keeping simple the SimpleDBPersistenceManager is a good option not
only for the sake of simplicity, but also because other approaches are
discouraged due to design decisions. As Stefan pointed a few times
jackrabbit is designed to stand in its own right. It means that it's
not designed to leverage any persistence storage engine, rdbms
included.

  The fact derby is the default PM doesn't mean it's the best option,
there's overhead related to sql parsing and too many unused features.
It took me a while to understand it :), but I agree that for now the
best option is a simple and transactional btree implementation, as
Stefan has been pointing for a long time. Something like
http://jdbm.sourceforge.net/ would probably be a better fit. Stefan,
WDYT?. Is it worth to give it a try?

Since questions about leveraging rdbms capabilities arises in the
Mailing list all the time, in case the comments above have any sense,
I suggest adding a few more entries to the faqs that make clear
Jackrabbit is not just a layer on top of a rdbms. WDYT?

e.g.
----

I want to use jackrabbit in a j2ee environment and I want to use JNDi
to configure jdbc connections, how can I do it?
You can override the default implementation and get connections
through JNDI, but take into account that using a rdbms in server mode
is not the best option. Jackrabbit *is* a storage engine by itself.

Does Jackrabbit leverage rdbms capabilities?
No, all Jackrabbit needs from a PersistenceManager implementation is a
simple transactional persistence mechanism that supports large
collections. A simple btree implementation suffice.

What's the benefits of using a jdbc based PM implementation?
Only the rdbms administrative stuff, scheduled backups, etc.

---

my 0,0002 cents, in case it worths that much ;)
edgar

ps, congratulations to all. you are all doing a great job!!

On 3/18/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 3/18/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> > 'Simple' also refers to use of a very simple data model instead of
> > a fully normalized schema or some object-relational mapping.
>
> Agreed. A different data model would require a fully separate PM class
> (like in the orm- or dbd- contribs). I believe the
> SimpleDbPersistenceManager data model is good for the current needs
> and pretty much orthogonal to the way the database connection is
> handled.
>
> > those best practices apply to j2ee applications. the point is that i don't
> > consider jackrabbit to be a j2ee application, jackrabbit is infrastructure
> > and has other requirements regarding its persistence layer than a
> > database application.
>
> Good point. In many cases Jackrabbit however lives in a J2EE
> environment and, as expressed in JCR-313, there are legitimate needs
> for using it within the constraints of existing database deployments.
>
> > note that write operations must occur within a single transaction, i.e.
> > you can't get a new connection for every write operation.
>
> Ah, good point. That pretty much downs my proposal. So, withdrawn for now.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
View raw message