hi marcel as far as the specific problem with the permission hook is concerned: moving to a repository initializer doesn't work IMHO for the following reasons:
a) being part of the overall access control configuration the permission stuff is pluggable at runtime. initializing this once in the very beginning will not work. b) if a new workspace is added the corresponding section in the permission store must be added as well. so, i would suggest to try moving this to a WorkspaceInitializer. may i ask you to create an issue for that? merci. kind regards angela On 4/25/13 12:23 PM, Marcel Reutegger wrote:
hi all, today I encountered a race condition in one of the commit hooks, which points to a more general problem. first the specific issue with the PermissionHook. it creates some nodes if they don't yet exist (/jcr:system/jcr:permissionStore/default) this happens with the first commit to a workspace. the problem now is, concurrent commits will fails when they are issues right after the repository is initialized. to solve this specific issue, we should probably move the code to a RepositoryInitializer. more generally, these kind of race conditions may also happen in other editors and hooks, even if the changes of some concurrent commits otherwise don't overlap. e.g. creating a versionable node will currently create a version history with some more or less randomly named ancestor nodes, which may overlap with other versionable nodes created at the same time. similarly the p2 index implementation may introduce a conflict in the :index storage because of its hierarchical layout even when changes triggering the index update don't conflict. I'd be interested to hear what people think about this problem. should we retry commits when these kind of conflicts where introduced by hooks or editor or do we require the latter to take care of this and only manipulate content in a non-conflicting way? regards marcel
