[
https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799075#comment-13799075
]
Konrad Windszus commented on JCRVLT-18:
---------------------------------------
That is still a problem for the default mode ImportMode.REPLACE
(https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/api/FilterSet.java)
if a node gets replaced which is having a lot of subnodes. The delete
operation will basically block for a long time in Jackrabbit 2 because the
autosave threshold is ignored for the delete operation. What would be better is
probably: Traverse through the old content and save after deleting 1000 leaf
nodes.
> Set default autosave threshold based on repository implementation
> -----------------------------------------------------------------
>
> Key: JCRVLT-18
> URL: https://issues.apache.org/jira/browse/JCRVLT-18
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Tobias Bocanegra
> Priority: Minor
>
> with jackrabbit 2.0 we had a limitation of the size of the transient space as
> it is held in memory. in order to support large packages, the AutoSave
> threshold is set to 1024 nodes.
> with jackrabbit 3.0 the transient space is more or less unlimited in size,
> and we can install large packages in 1 save, which improves installation
> atomicity.
> however, the bigger the transient size, the higher the chance for collisions
> during installation of large packages, so saving in chunks yields to a more
> robust installation behavior.
> suggestions:
> - autosave threshold of 0 should mean 'auto'
> - autosave threshold of -1 should mean 'never'
> - packages can provide their desired autosave threshold via properties
--
This message was sent by Atlassian JIRA
(v6.1#6144)
