Padraic Hannon wrote: > 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). Jackrabbit must support JTA if it wants to support TXs according to the JCR Spec (see previous discussion, http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06525.html). At the moment, this is a spec violation IMO: JR says it supports TXs but w/o JTA support.
Should a ticket be opened for this, BTW? Solution would be either JTA support, or not supporting TX. > 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 >> >
