If Jackrabbit is to be the database then things such as transaction
isolation levels, etc. need to be addressed. If Jackrabbit uses a
database (ie derby) some of those can be off loaded to the db. However,
in that case Jackrabbit becomes yet another, albeit extremely
interesting, wrapper around an RDBMS. I think Jackrabbit is much more
than an RDBMS wrapper and that developing the API is just a part of the
overall system. IMO, moving away from derby and into a native storage
system sounds like the right direction.
Jukka Zitting wrote:
Hi,
Late night ramblings...
There's recently been a lot of talk about managing the database
connections (and transactions) of the Jackrabbit persistence managers.
It was even suggested that Jackrabbit be refactored so that each
session would map to a separate database connection.
Improvements in the way an underlying database is used are of course
welcome, but in the big picture I don't like having the database being
a driving factor in Jackrabbit design. The way I see it we should be
moving further away from relational databases, towards a native
hierarchical storage model.
I don't want Jackrabbit using a database, I want Jackrabbit *being*
the database!
BR,
Jukka Zitting
