Hi,
Are there any plans (or has someone already done) a CassandraMK
I'm not aware of plans to write a CassandraMK. Currently we concentrate on
MongoDB. Possibly Cassandra could be supported quite easily by
implementing the org.apache.jackrabbit.mongomk.prototype.DocumentStore
interface, but I
Hi,
(/libs is always consistent,
/comments is eventually consistent or so).
I think (but dont know for certain) that that would require the paths
being store in different column families.
Yes, that's true.
Is it possible to
differentiate between subtrees at the DocumentStore interface level
So you essentially say: Behaviour of the repository is best effort and we --
at the end of the day -- cannot trust the repository ?
Sounds frightening.
IMHO the repository should be failsafe and thus eventually solve the issue
making sure we don't end up with two copies of the same node
What Jukka is saying is that the repository gives you a choice between
consistency and availability. Since both you cannot have.
Michael
On 1.3.13 12:40, Felix Meschberger wrote:
So you essentially say: Behaviour of the repository is best effort and we --
at the end of the day -- cannot
Hi,
Am 01.03.2013 um 13:47 schrieb Michael Dürig:
What Jukka is saying is that the repository gives you a choice between
consistency and availability. Since both you cannot have.
I think you don't want to given the user that choice ...
I'd opt for best possible availability (or probably
On Fri, Mar 1, 2013 at 4:47 AM, Michael Dürig mdue...@apache.org wrote:
...What Jukka is saying is that the repository gives you a choice between
consistency and availability. Since both you cannot have
+1 to having that, as long as those choices are made clear to users.
Log messages that
Hi,
What Jukka is saying is that the repository gives you a choice between
consistency and availability. Since both you cannot have.
Actually, I challenge this. You can have both consistency and availability
at the same time. I guess you refer to the CAP theorem, which says you
can't have all of
Hi,
One point of Oak is exactly that: to provide a sensible way for trading
off consistency for availability.
As far as I understood our goals, we want to have a scalable solution.
While I agree that consistency is
important it should however not have an impact on scenarios where it is
On 2 March 2013 01:38, Thomas Mueller muel...@adobe.com wrote:
Hi,
One point of Oak is exactly that: to provide a sensible way for trading
off consistency for availability.
As far as I understood our goals, we want to have a scalable solution.
While I agree that consistency is
important it
Hi,
I'm wondering how move operations in a cluster will work in Oak - my
scenario is that more than one cluster node tries concurrently to move
a node to a different location, but each of the instances tries to
move the same source to a different destination. So e.g. we have a
node at /a/node and
Hi,
On Wed, Feb 27, 2013 at 5:09 PM, Carsten Ziegeler cziege...@apache.org wrote:
How will this be handled with Oak? Could it happen that due to this
happening concurrently that the node ends up twice in the repository
(at /1/node and /2/node in my example)?
The behavior depends on the
Thanks Jukka,
is the configuration of the journal a repository wide configuration or
is it configurable for sub trees?
Regards
Carsten
2013/2/27 Jukka Zitting jukka.zitt...@gmail.com:
Hi,
On Wed, Feb 27, 2013 at 5:09 PM, Carsten Ziegeler cziege...@apache.org
wrote:
How will this be
Hi,
With the MongoMK I'm working on, the first move would work, and the second
move would fail.
Regards,
Thomas
13 matches
Mail list logo
