jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Remoting granularity (Was: [jira] [Commented] (OAK-80) Implement batched writing for KernelNodeStore)
Date Thu, 03 May 2012 12:16:44 GMT
On Wed, May 2, 2012 at 5:26 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> [new thread, since this is a broader issue than OAK-80]
>
> On Wed, May 2, 2012 at 4:50 PM, Thomas Mueller (JIRA) <jira@apache.org> wrote:
>> The question is how would you build an an efficient oak-core remoting, if every
>> Node.setProperty requires a TCP/IP roundtrip, because it goes through oak-core
>>  and down to oak-mk?
>
> Good question.
>
> Instead of always mapping method calls directly to remote roundtrips
> (like for example JCR-RMI does), batching and caching of content
> should be up to the remoting implementation to deal with.
>
> I don't think such concerns should be baked in to the Oak API (or the
> MK for that matter), as no single solution will work for all clients
> and deployment scenarios. For example, it makes little sense for a
> local client to have to batch changes in memory or on some custom disk
> location just because doing so is necessary for a remoting layer.

maybe i am missing something, but IMO it's obvious that remoting
should be on the oak-jcr/oak-core boundary. it doesn't make sense
to remote the JCR api methods 1:1 (as in JCR-RMI). i don't see any
problem with batching transient changes in oak-jcr (local or remote backend).

IMO this approach worked quite well in jcr2spi and the various spi2...
implementations.

chees
stefan

>
> BR,
>
> Jukka Zitting

Mime
View raw message