Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4339587D.8020008@jahia.com>
Date: Tue, 27 Sep 2005 16:34:37 +0200
From: Serge Huber <shuber2@jahia.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Is JDBC persistence manager supported by jackrabbit?
References: <20050716042756.66476.qmail@web32702.mail.mud.yahoo.com>
 <42D907A2.8070408@gmail.com> <df4m4f$s8s$1@sea.gmane.org>
 <43167705.1030608@gmail.com>
In-Reply-To: <43167705.1030608@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hi Edgar,

I was away for 3 weeks at the army so sorry for the late reply.

> The main problem to store the itemstates in a complex schema is the 
> Collection handling. Since Collection fields changes are not logged 
> into add/update/remove aware objects, all the elements in the 
> Collection must be stored on each write call. It causes a hit on 
> performance when handling collections with lots of elements, even with 
> the simple PMs included in the core.

Actually there is a way to do that, and that is why I had custom 
implementations of the NodeState and PropertyState, so that I could use 
add/update/remove aware objects. Both Hibernate and OJB do this 
differently, but if implemented correctly, you do not have to rewrite 
the whole collection all the time.

But I ran into trouble because I had to copy the data between the 
original item state and my internal objects. That is why the 
implementation is so complex. If I could have re-used the objects as-is 
I would have had this problem, but this way not possible because I 
needed to modify the collection implementations. Maybe there is a way to 
do this using aspects, but this would complicate things even further.

With the hindsight, for high-performance, transaction-aware and cluster 
compliant, there is no perfect solution. I don't really like the 
file-system BLOB solution because it causes problems with replication. 
The RMI-cluster solution is interesting, but I worry about 
connection/disconnection problems. The full database implementation 
causes performance problems, especially for binary data. Basically what 
this means is that we are implementing some sort of clustered 
file-system, that supports transactions and is as high-performance as 
possible.

Regards,
  Serge Huber.