Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <09021F9D-3C26-4C2F-989C-7F0DD8ADD229@adobe.com>
References: 
 <CAOFYJNb88iwYpX0w=yQsP_3yTTUnM3QqezBv-Dui8wPbuAOEbw@mail.gmail.com>
 <09021F9D-3C26-4C2F-989C-7F0DD8ADD229@adobe.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Wed, 18 Apr 2012 09:06:20 +0200
Message-ID: 
 <CAOFYJNby-N6O2Be-zgvO4Z_6xCSuMKdejs2eQR9J6Gyr6O5DXg@mail.gmail.com>
Subject: Re: Oak API - a top down look
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Apr 18, 2012 at 8:51 AM, Felix Meschberger <fmeschbe@adobe.com> wro=
te:
> IIUIC there is no notion of a workspace here, right ? So to implement JCR=
 workspaces,
> those might be to top level ContentTree below the root ?

We can handle this in two ways:

1. Specify the workspace name as a parameter to either login() or
getCurrentContentTree().
2. Have the root ContentTree represent the entire repository with
workspaces below it as subtrees.

Personally I'd prefer option 2 since it makes it much easier to handle
cross-workspace operations, but there are complications with login()
that's in Jackrabbit 2 more or less workspace-specific.

>> All `ContentRepository` and `ContentSession` instances are thread-safe.
>> ...
>> `ContentTree` instances are *not* thread-safe...
>
> I think it is a good thing to clearly state thread-safe-ness. But I am wo=
rried
> about ContentTree not being thread-safe..

By declaring as not thread-safe, we avoid having to worry about
synchronization and concurrent access in a lot of fairly complicated
bits of code (refresh, commit, etc.). And since a client can easily
acquire any number of parallel ContentTree instances, ensuring
thread-safety shouldn't be a problem for the client.

>> =A0 =A0ContentTree tree =3D ...;
>> =A0 =A0ContentTree subtree =3D tree.addSubtree("hello");
>> =A0 =A0subtree.setProperty("message", "Hello, World!");
>> =A0 =A0tree.commit();
>
> Particularly this one worries me most: We are now leaving the turf of imm=
utable value
> objects again and enter concurrency problem prone terrain ...

As mentioned above, these trees are only mutable by the client, so
there's no need to worry about concurrent changes from elsewhere. So
for example traversing through the content tree will never encounter
concurrent changes unless the client itself modifies things. And the
underlying content model at the MicroKernel level is still fully
immutable.

BR,

Jukka Zitting