Hi Marcel,
On 21/08/07, Marcel May [EMAIL PROTECTED] wrote:
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
On 21/08/07, Padraic Hannon [EMAIL PROTECTED] 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).
hi all,
i can appreciate both positions, looking at jackrabbit as the datastore
or looking at jackrabbit as running on top of a datastore (rdbms).
personally, i don't believe that the latter perception will go away for
quite a while, so i think jackrabbit should support both views.
in my
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
Hi,
For me, the question is not really databases or not (databases need to
be supported, while native storage can be much faster).
My question is: should we support multiple connections in the
persistence manager?
If using multiple connections really does improve performance /
scalability of
On 8/21/07, Michael Wechner [EMAIL PROTECTED] wrote:
well, I want my local filesystem accessible via JCR and allowing me to
change files still with vi(m) from time to time
This works, whatever storage mechanism is used, but in the opposite
way: you can mount a Jackrabbit repository via
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
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
Hi,
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.
Thomas
On 8/18/07, Jukka Zitting [EMAIL PROTECTED] 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
Hi,
moving away not only from RDBMS systems as core storage
I agree. RDBMS are not the best way to store hierarchical data.
but also away from their query languages such as SQL.
SQL is a very old and strange language. It does not fit very well with
languages such as Java. Replacing it would
On 8/18/07, Jukka Zitting [EMAIL PROTECTED] wrote:
I don't want Jackrabbit using a database, I want Jackrabbit *being*
the database!
+1 but we need more administration tools. I mean in the open source area :-)
BR,
Jukka Zitting
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
On a similar subject, has any one looked at Freebase? It is built upon
Metaweb which is described in their manual as: A Metaweb database is a
sea of knowledge organized as a graph: a set of nodes and a set of links
or relationships between those nodes.
After playing with it for a while it is
14 matches
Mail list logo
