jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Whitacre <mkwhita...@gmail.com>
Subject Re: Improve performance on Node.checkin() with a lot of children
Date Wed, 21 Jan 2009 19:21:05 GMT
Hmm that clarifies and explains what I am seeing and why I am seeing
that behavior.  However I'm assuming if I were to alter that property
(to what value I'm not sure) I would lose the ability to retrieve the
child nodes at the time the version was created from the frozen node?
So code like this would no longer work:

Version version = node.getBaseVersion();
Node versionNode = version.getNode("jcr:frozenNode");
NodeIterator it = node.getNodes();
//it would contain all my child nodes.

Wouldn't that negate the benefit of having versioned nodes if I
couldn't retrieve the state of the repository for a certain version?

Thanks for your help,

On Wed, Jan 21, 2009 at 10:54 AM, Diego Marin Santos
<diegomrsantos@gmail.com> wrote:
> Page 239 in JSR 170:
> "Those versionable child nodes of N (i.e., children of N that are
> themselves also versionable) with OnParentVersion=VERSION are
> dealt with in a special way: a node with the same name as the child
> node but of type nt:versionedChild is placed as a child of
> jcr:frozenNode. This special node is not a copy of the child node
> of N but instead holds a single reference property (called
> jcr:childVersionHistory) that points to the version history of
> the child of N. The OnParentVersion mechanism has other options
> as well, for a full discussion, see 8.2.11 The OnParentVersion
> Attribute."
> If you see the *OnParentVersion* attribute in *ChildNodeDefinition * found
> in NodeDefinition of  the node type nt:folder, you'll discover that its
> value is
> VERSION and, because of that, the actions above are executed for the 700
> child nodes. Maybe that's the cause of the delay.
> Regards
> 2009/1/21 Micah Whitacre <mkwhitacre@gmail.com>
>> Hey All,
>>  I'm wondering if there is any easy way to alter my configuration or
>> setup to improve performance on when saving a node that has a lot of
>> children.  So an example of the setup I have is:
>> node <- nt:folder and with mixin type of versionable.
>>    /child_1
>>    /child_2
>>    ....
>>    /child_n
>> As n gets larger it becomes slower and slower to add child_n+1 (rough
>> estimate as n = 700 it takes about 10s to add each child).  The way
>> the code looks to add the new child looks like the following:
>> node.checkout();
>> Node child = null;
>> try {
>>     child = node.addNode("child_X", "nt:folder");
>>     child.addMixin("mix:versionable");
>>     child.checkout();
>>     node.save();
>> } catch (ItemExistsException iee) {
>>      //do stuff
>> } finally {
>>          node.checkin();
>> }
>> child.checkin();
>> Using JProbe it seems that most of the time is spent in the
>> "node.checkin()" method call (when looking at cumulative time).  For
>> my use case the nodes need to be versionable and I'd assume that as
>> the children of a node increased there would be a performance hit but
>> I guess I assumed it would be for a larger number of children.  My
>> <Versioning/> configuration in the repository.xml looks like the
>> following (values such as db.url/db.username/db.password are replaced
>> before creating the RepositoryConfig object):
>>   <Versioning rootPath="${rep.home}/version">
>>      <FileSystem
>>         class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
>>         <param name="url"
>>            value="${db.url}" />
>>         <param name="schemaObjectPrefix" value="conf_v1_ver_" />
>>         <param name="user" value="${db.username}" />
>>         <param name="password" value="${db.password}" />
>>      </FileSystem>
>>      <PersistenceManager
>> class="org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager">
>>         <param name="url"
>>            value="${db.url}" />
>>         <param name="user" value="${db.username}" />
>>         <param name="password" value="${db.password}" />
>>         <param name="schemaObjectPrefix" value="conf_v1_ver_" />
>>         <param name="externalBLOBs" value="false" />
>>      </PersistenceManager>
>>   </Versioning>
>> My setup is that I'm currently consuming jackrabbit-core 1.4.6 with
>> jdk 1.5.0_11.  Multiple web services in multiple JVMs read and write
>> to the same repository so I have clustering turned on to synchronize
>> them.  So I am curious if this is a known limitation of
>> Jackrabbit/versioning, if I am doing something wrong in my code, or if
>> there is a configuration change I could make to get a performance
>> boost.
>> Thanks in advance for any help,
>> Micah

View raw message