On Sat, Jan 14, 2017 at 2:08 AM, lancedolan <[email protected]> wrote:
> To be honest, however, I don't understand fully
> what you said in your last post and I also know that AEM 6.1 can do what I'd
> like, which is really just Sling+Oak. If they can do it, I don't understand
> why we can't.
>
> ref:
> https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html
That links talks about scaling of publish instance which are in most
cases based on Segment/Tar setup and hence not forming a "homegenous"
cluster. Each cluster node has separate segment store and only
potentially shares the DataStore
> B) There are separate versions of that property stored in Mongo (perhaps
> this is what you meant by the word revision) and it's possible for a
> sling-instance to be reading an old version of a property from Mongo.
Thats bit closer to whats happening. [1] talks about the data model
being used for persistence in Mongo/RDB. For example if there is a
property 'prop' on root node i.e. /@prop then its stored in somewhat
following form in Mongo
{
"_id" : "0:/",
"prop" : {
"r13fcda91720-0-1" : "\"foo\"",
"r13fcda919eb-0-1" : "\"bar\"",
}
}
The value for this property is function of revision at which read
operation is performed. So 'prop' value is 'foo' at rev r1 and 'bar'
at rev r2. These revisions are based on timestamp. Now each cluster
node also has a "head" revision. So any read call on that cluster node
would only see those values whose revision are <= '"head" revision.
This head revision is updated periodically via background read. Due to
this snapshot isolation model you see the write skew [2]
Chetan Mehrotra
[1] https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html
[2] https://jackrabbit.apache.org/oak/docs/architecture/transactional-model.html
