On Fri, May 16, 2008 at 2:31 PM, Tobias Bocanegra <[EMAIL PROTECTED]> 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
