Remoting granularity (Was: [jira] [Commented] (OAK-80) Implement batched writing for KernelNodeStore)

[Jukka Zitting <ju...@gmail.com>]

Hi,

[new thread, since this is a broader issue than OAK-80]

On Wed, May 2, 2012 at 4:50 PM, Thomas Mueller (JIRA) <ji...@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.

BR,

Jukka Zitting

Re: Remoting granularity (Was: [jira] [Commented] (OAK-80) Implement batched writing for KernelNodeStore)

[Stefan Guggisberg <st...@gmail.com>]

On Wed, May 2, 2012 at 5:26 PM, Jukka Zitting <ju...@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) <ji...@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