I concur, relational semantics should be buried within the persistence
managers. However, I think that one can still delegate transaction
handling using JTA to the container rather than using synchronization
and connection.autocommit(false). Obviously this should be configurable.
Regardless of wether Jackrabbit wraps an underlying RDBMS or not
transaction management, esp. in a clustered environment, being handled
via the facilities available from one's container should reduce
application complexity. Otherwise, one has to go to jgroups or some
other project and embed that code which makes configuration/management
more difficult in a production environment. I suppose one could write an
admin console or expose via JMX admin functionality, however, some of
this would be duplicative of the configuration of the container.
-paddy
Jukka Zitting wrote:
Hi,
On 8/20/07, Thomas Mueller <[EMAIL PROTECTED]> wrote:
management won't.
political reasons.
won't move to Jackrabbit *if* Jackrabbit cannot store it in oracle.
I agree. My guess is about 50% of larger organizations want a
databases as the backend, even if databases are slower. So about 50%
don't really care.
Agreed, that's my understanding as well.
I don't mind things like the current database persistence managers (as
long as the persistence interface doesn't require a database), but I
strongly feel that suggestions about pushing relational semantics or
other similar database concepts higher up in the Jackrabbit
architecture would be taking us to the wrong direction.
Even though existing relational databases do provide a solution to
many of the currently missing or partially implemented pieces in
Jackrabbit (backup, clustering, etc., most notably a huge user and
administrator base), a relational database will never be an optimal
storage for the hierarchical content model in JCR.
Essentially, in 5-10 years when we hopefully will start seriously
optimizing for performance and scalability, I don't want us in a
situation where we need to change the whole underlying architecture to
reach real performance gains.
BR,
Jukka Zitting
