On 16.10.13 9:45 , Jukka Zitting wrote:
Yes this should work (even though I'm not too fond of using thread locals).
An cleaner alternative to a ThreadLocal would be to use an extra
commitinfo argument to carry the information down the stack through
the relevant commit and merge methods
Th
Hi,
On Wed, Oct 16, 2013 at 2:58 PM, Michael Dürig wrote:
> Well there is the extra benefit for transporting that info across cluster
> nodes.
I don't see the benefit. There's no reliable way to match such
external commitinfos to the respective content changes, so we can't
use that information
On 16.10.13 6:36 , Jukka Zitting wrote:
Hi,
On Wed, Oct 16, 2013 at 11:47 AM, Michael Dürig wrote:
On 16.10.13 5:23 , Jukka Zitting wrote:
I don't think this is a good idea.
Why?
You're essentially passing information from Root.commit() a few levels
down the stack to ChangeDispatcher.lo
Hi,
On Wed, Oct 16, 2013 at 11:47 AM, Michael Dürig wrote:
> On 16.10.13 5:23 , Jukka Zitting wrote:
>> I don't think this is a good idea.
>
> Why?
You're essentially passing information from Root.commit() a few levels
down the stack to ChangeDispatcher.localCommit(). Routing that
information th
Hi,
On Wed, Oct 16, 2013 at 10:43 AM, wrote:
> - Use :commit-info on the root node to pass commit information across
I don't think this is a good idea. Instead I'd use a ThreadLocal or
just pass the extra information as an extra argument in the commit
call.
BR,
Jukka Zitting
> The lucene index is asynchronous
Okie I missed that part completely i.e. OAK-763. Yup with that used
for such indexers this problem would not be observed.
Thanks for the pointer Alex!!
Chetan Mehrotra
Hi Chetan,
The lucene index is asynchronous and the way it works is it (periodically)
branches the current state and runs a diff to update the index data. [0]
This shouldn't include the conflicts you refer to, but I may be wrong here.
My guess is the solr index will pass on an async model too, so
Hi,
Currently the various IndexEditor (Lucene,Property and Solr) are
invoked as part of CommitHook.processCommit call whenever a JCR
Session is saved.
In case the commit fails would it leave the Index state in inconsistent state?
For PropertyIndex I think it would be fine as the index content is
we should probably also consider upgrading the java driver. the
default write concern changed with 2.10.0:
http://docs.mongodb.org/manual/release-notes/drivers-write-concern/#driver-write-concern-change
the default is now equivalent to SAFE aka ACKNOWLEDGED.
regards
marcel
> -Original Messa
On 15.10.13 8:04 , Tobias Bocanegra wrote:
I think the semantics of NodeType.equals() should be mentioned in the JCR
API. I'm indifferent if we should consider the comparison between 2
different implementations.
The symmetry requirement comes from the general contract of equals and
we can't
On 15.10.13 6:29 , Jukka Zitting wrote:
Hi,
On Tue, Oct 15, 2013 at 12:21 PM, wrote:
Added:
jackrabbit/site/live/oak/docs/META-INF/
jackrabbit/site/live/oak/docs/META-INF/DEPENDENCIES
jackrabbit/site/live/oak/docs/META-INF/LICENSE
jackrabbit/site/live/oak/docs/META-INF/N
11 matches
Mail list logo
