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: Package deployment check for locking leading to large no of small branch commits
Date Wed, 18 Dec 2013 07:45:01 GMT
Hi,

> On Tue, Dec 17, 2013 at 12:26 PM, Chetan Mehrotra
> <chetan.mehrotra@gmail.com> wrote:
> > So not sure where the fix is to be done. Should lock check be also
> > restricted to version at which session is pinned or one needs to be at
> > latest revision?
> 
> Since the lock checks are normally used to synchronize work across
> sessions, it doesn't make much sense for it *not* to refresh.

I definitively agree when it comes to locking a node. this should be done
on a refreshed session. but what is the value in just checking if a node
is locked?

I don't think you can build reliable code with this behavior anyway. the
lock status of a node may change as soon the isLocked() method returns
and you cannot rely on what it reports. usually you have code that
must modify content only with a lock held. in this case you will have
to call lock() anyway, which performs a refresh.

> Instead I'd look for a fix in steps 3 or 6:
> 
> 3. Does the ImporterImpl really need to explicitly check for locking,
> or would that be better handled by a commit hook? The same applies BTW
> for the versioning check.
> 
> 6. Since there's no need for a branch to be visible to any other
> clients, a branch commit could (and probably should) remain in local
> memory unless or until the transient space grows too large. This way
> the performance overhead of the refresh should be minimal.

not sure here, but I think the reason why we push the changes into
the branch is that we can perform a rebase on the underlying store.
e.g. the MicroKernel. how would you rebase a branch partially in
memory and persisted?

Regards
 Marcel

Mime
View raw message