jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Next Generation Persistence
Date Fri, 13 Apr 2007 21:44:47 GMT
Hi,

On 4/13/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> It sounds to me more like the transient space needs its own backing
> store mechanism.  It doesn't make sense for unsaved changes to
> be sent across the SPI, for the same reason it doesn't make sense
> to send workspace edits to the subversion repo before an explicit
> commit.

I fully agree when the SPI is used as a remoting layer, but I don't
think it's necessary or even beneficial to have a separate backing
store mechanism for the transient space when accessing a local
repository. I also believe that the most performance-critical
deployments will use either fully local or very low-latency network
connections to the repository backend. You wouldn't want your
performance-critical CMS application to access the content repository
over the Internet.

As of now the SPI layer implies making an extra copy of transient
changes. It is possible to avoid extra copying of binary (and other)
values with the current SPI, but transient spaces with large numbers
of nodes and properties still face this problem. I'm wondering if we
could modify the SPI somehow to allow the client to only keep track of
item identifiers instead of the full transient item states and let the
SPI implementation decide whether to use a separate client-side
backing store for the item states.

BR,

Jukka Zitting

Mime
View raw message