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 <[email protected]> > 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 >
