jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: Drop PropertyState?
Date Mon, 19 May 2008 09:51:15 GMT
On Fri, May 16, 2008 at 2:31 PM, Tobias Bocanegra <tobias.bocanegra@day.com>
wrote:

> >  >>  (Another potential iterative step could be for example storing
> entire
> >  >>  bundles in the journal, and implementing a persistence manager that
> >  >>  gets its content from the journal instead of a separate storage.)
> >  > ..and the changelog. so that the modifications of a transaction are
> >  > direclty store the the journaled persistence manager and the commit
> >  > would result it marking the changes as active.
> >
> >
> > Good point! Handled correctly, that would even cover some of the
> >  memory issues related to large transient or directly persisted
> >  operations.
> i think this might by a change (introduce tx aware pms) that we could
> introduce independently from the 'drop property state' issue.
>

In the light of an improved PM interface (NGP, journaled PM or whatever
solution will be best), we should not be constraining the PM how it has to
store data by reducing the methods and forcing it to use bundles (node +
properties + property values in one bundle). For example, the lack of
hierarchy information in the current PM interface makes it impossible for a
backend to improve hierarchy-specific reads (eg. getNodeChildren). Forcing
the concept of bundles into the PM would introduce the same problem.

IMHO it is possible to have a larger set of methods than the current PM, but
still implement it in a bundle-style. It's just about the right abstraction.
I started some work about this recently, which might help in identifying a
good interface for a journaled PM, that could even include the transient
space (for non-memory bound clients). I hope to continue it in the coming
weeks to get a basis for discussion.

Just my 2 cents...
Alex

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message