jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Padraic Hannon <...@wasabicowboy.com>
Subject Re: Jackrabbit, the database
Date Tue, 21 Aug 2007 16:07:28 GMT
I concur, relational semantics should be buried within the persistence 
managers. However, I think that one can still delegate transaction 
handling using JTA to the container rather than using synchronization 
and connection.autocommit(false). Obviously this should be configurable. 
Regardless of wether Jackrabbit wraps an underlying RDBMS or not 
transaction management, esp. in a clustered environment, being handled 
via the facilities available from one's container should reduce 
application complexity. Otherwise, one has to go to jgroups or some 
other project and embed that code which makes configuration/management 
more difficult in a production environment. I suppose one could write an 
admin console or expose via JMX admin functionality, however, some of 
this would be duplicative of the configuration of the container.


Jukka Zitting wrote:
> Hi,
> On 8/20/07, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
>>> management won't.
>>> political reasons.
>>> won't move to Jackrabbit *if* Jackrabbit cannot store it in oracle.
>> I agree. My guess is about 50% of larger organizations want a
>> databases as the backend, even if databases are slower. So about 50%
>> don't really care.
> Agreed, that's my understanding as well.
> I don't mind things like the current database persistence managers (as
> long as the persistence interface doesn't require a database), but I
> strongly feel that suggestions about pushing relational semantics or
> other similar database concepts higher up in the Jackrabbit
> architecture would be taking us to the wrong direction.
> Even though existing relational databases do provide a solution to
> many of the currently missing or partially implemented pieces in
> Jackrabbit (backup, clustering, etc., most notably a huge user and
> administrator base), a relational database will never be an optimal
> storage for the hierarchical content model in JCR.
> Essentially, in 5-10 years when we hopefully will start seriously
> optimizing for performance and scalability, I don't want us in a
> situation where we need to change the whole underlying architecture to
> reach real performance gains.
> BR,
> Jukka Zitting

View raw message