jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel May <marcel....@consol.de>
Subject Re: Jackrabbit, the database
Date Tue, 21 Aug 2007 16:38:00 GMT
Padraic Hannon wrote:
> 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). 
Jackrabbit must support JTA if it wants to support TXs according to the
JCR Spec
(see previous discussion,
http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06525.html).
At the moment, this is a spec violation IMO: JR says it supports TXs but
w/o JTA support.

Should a ticket be opened for this, BTW?
Solution would be either JTA support, or not supporting TX.

> 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.
>
> -paddy
>
>
> 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
>>   
>

Mime
View raw message