[jr3] Micro-kernel vs. new persistence

[Alexander Klimetschek <ak...@day.com>]

Hi all,

the jr3 discussions are currently both about a better persistence
interface (micro-kernel) that is generic enough for different
persistence implementations and on the other hand we are talking about
features for a new "default" high-performance (excuse me for that
term) persistence implementation (eg. what indexes to use, transaction
log, etc.).

I think these tend to conflict with each other, since concentrating on
a single optimized persistence impl might make the micro-kernel not
generic enough. A good abstraction can mostly only be found if you
actually have all use cases at hand. Vice-versa, concentrating on a
generic (and/or simple) micro-kernel interface might block certain
optimizations in the underlying implementation (see the current
persistence manager).

But do we have other persistence ideas? And if we have them, isn't
that too much effort at once? Or do we have enough experience already
to "hit the nail" with the new micro-kernel interface? Where are our
priorities?

Regards,
Alex

PS: sorry for that ;-)

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Micro-kernel vs. new persistence

[Guo Du <mr...@gmail.com>]

On Thu, Mar 4, 2010 at 12:21 PM, Thomas Müller <th...@day.com> wrote:
> I think the storage API should support some kind of "storage session"
> (normally one storage session for each JCR session). For a relational
> database, such a session could map to a database connection.

I think the session.save() should be transactional and bounded to storage
transactional control API if available. In this case jdbc connection
transaction.

Because jdbc transaction has different isolation level, it may not
safe to share
the connections between jcr sessions. Any one see the problem/drawback to
use a connections pool and use a jdbc connection per jcr session?


> features for a new "default" high-performance (excuse me for that
> term) persistence implementation (eg. what indexes to use, transaction
I am not too much concern with the performance if it's not terrible bad
compare with what we have now. That's the price we paid for the feature
we got. User may look for other technology to meet their performance
if it's a problem.

-Guo

Re: [jr3] Micro-kernel vs. new persistence

[Thomas Müller <th...@day.com>]

Hi,

I think the persistence / storage API should be generic enough to
support at least 3 different implementations efficiently:

- an implementation based on a relational database
- a file based implementation
- in-memory

I think the storage API should support some kind of "storage session"
(normally one storage session for each JCR session). For a relational
database, such a session could map to a database connection.

In my view the persistence should be based on "bundles" (node with all
property values and with the list of child nodes) as it is now; maybe
there should be a way to combine multiple bundles into one.

Probably there should be a way to persist the transient space (only
when it doesn't fit in memory). Otherwise we would need to implement a
separate mechanism for that (using temporary files).

I think the "data store" API can be used as it is (maybe we can
simplify it a bit).

Regards,
Thomas