jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Considering Jackrabbit
Date Tue, 19 Jul 2005 08:15:40 GMT
David Nuescheler wrote:

>>- to be able to handle transactions
>>- to be able to handle commit/rollback
>true... what is the difference between the two points?
Well if you think in terms of pure JDBC then there is no difference. But 
for me transactions also cover memory state, so any objects handled by 
the PM (that are not also handled by the upper layers) should also be 
reverted in case a transaction fails. This of course is only necessary 
if your PM implementation has internal caches, or uses copies of 
Jackrabbit objects.

>>- use mapping files to be able to change the table and column names as
>>they might conflict
>not sure. of course there are a number of different ways on how 
>someone could map a content repository to a relational database.
>however, i think there are a couple of very simple "hard coded" 
>implementations that completely avoid conflicts without 
>any configuration beyond standard jdbc.
Well from experience I know that table and column naming is something 
you will want to change at some point (I had the case where I had to 
integrate with a DB that required very short names). It doesn't cost 
much for example to make the statements loadable from a database (I 
believe Edgar's implementation does this). In the case of the iBatis 
implementation this was also the case. There is no performance cost to 
do this (as it is done during PM initialization), and allows for some 

>>- allow for clustering
>that is unfortunately not something that the pm can take care of
>see the jira bug and all the discussions around that.
I guess a better wording might be "- doesn't introduce any problems for 
clustering" then :) I have been following all the discussion of 
clustering, and I do agree that there is much more to it than just the PMs.

>see above. i think the differentiators that orm brings to the table
>are not that significant to a persistence manager, while i think that 
>the additional complexity is substantial.
Indeed the complexity worries me too. I'll have to have a go at it and 
see if I can simplify.

>>And as always, in terms of speed : memory > filesystem > db :)
>well, not in general ;)
Uh... I'm not sure you read this right. I meant to say that memory 
access is always faster than filesystem access which itself is faster 
than DB access. I would think this would be the general case. Of course, 
there can be exceptions (especially when the access design is not 


View raw message