jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: race conditions in commit hooks/editors
Date Thu, 25 Apr 2013 12:13:18 GMT
see: https://issues.apache.org/jira/browse/OAK-797

regards
 marcel

> -----Original Message-----
> From: Angela Schreiber [mailto:anchela@adobe.com]
> Sent: Donnerstag, 25. April 2013 13:20
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: race conditions in commit hooks/editors
> 
> 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
> >

Mime
View raw message