On 29.2.12 15:45, Marcel Reutegger wrote:
Vector clocks. See the presentation [1] which I prepared for the last F2F.
I understand this would require tagging each node with a timestamp, right?
If that's the case, then it's not just about complexity, but also additional
storage
So, this could result in a save on P that initially succeeds but
ultimately fails, because the concurrent one on Q wins? I'm wondering
how this could be reflected to an MK client: if a save corresponds to
a MK commit call that immediately returns a new revision ID, would you
suggest that the
Hi,
I understand this would require tagging each node with a timestamp,
right?
If that's the case, then it's not just about complexity, but also
additional
storage requirements.
If the node id is a counter, then there is no additional storage
requirement.
Regards,
Thomas
I understand this would require tagging each node with a timestamp,
right?
If that's the case, then it's not just about complexity, but also
additional
storage requirements.
If the node id is a counter, then there is no additional storage
requirement.
but in a distributed setup we
Hi,
but in a distributed setup we cannot just use a simple counter.
I believe with vector clocks you can, see
http://en.wikipedia.org/wiki/Vector_clock
Regards,
Thomas
Hi,
Am 28.02.2012 um 18:21 schrieb Jukka Zitting:
Otherwise
we'll just continue down the path where everyone has their own
MicroKernel implementation.
I don't think this is bad per se .. in fact it could be the source of better
implementations.
It may even end up with two implementations
Hi,
On 3/1/12 11:18 AM, Felix Meschberger fmesc...@adobe.com wrote:
Hi,
Am 28.02.2012 um 18:21 schrieb Jukka Zitting:
Otherwise
we'll just continue down the path where everyone has their own
MicroKernel implementation.
I don't think this is bad per se .. in fact it could be the source of
Hi,
recently I was thinking about an approaches to implement
clustering in JR3 and I'd like to know what you think about it.
Distributed B-tree
the clustering ideas we discusses so far [0] partition the tree at
given paths similar to mount points in a file system. I think
the drawback of those
Hi,
I have thought a bit about how one could go about implementing a micro kernel
based on a NoSQL database (think Cassandra or Mongo) where a JCR node would
probably be stored as an individual document and the MK implementation would
provide the tree on top of that. Consider that you have two
Hi Michael,
Are you suggesting, that cluster sync will be provided purely by the underlying
NoSQL database? Until now, I always assumed that all cluster nodes expose an MK
interface, and that changes are transmitted to other nodes via calls on this MK
interface. So in your example, cluster
Hi Marcel,
Nice to see new ideas wrt. to clustering. I quickly skimmed over the HP
paper and think that approach sounds promising. Having a flexible
partitioning scheme which also supports dynamic repartioning (i.e.
additions of server, migration of nodes) seems a better approach to me
than
Hi Dom,
Are you suggesting, that cluster sync will be provided purely by the
underlying NoSQL database?
Yes, that's what I meant.
Michael
--
Michael Marth | Engineering Manager
+41 61 226 55 22 | mma...@adobe.com
Barfüsserplatz 6, CH-4001 Basel, Switzerland
On Mar 1, 2012, at 2:25 PM,
On Thu, Mar 1, 2012 at 2:53 PM, Michael Marth mma...@adobe.com wrote:
Hi Dom,
Are you suggesting, that cluster sync will be provided purely by the
underlying NoSQL database?
Yes, that's what I meant.
well that's one possible approach.
cheers
stefan
Michael
--
Michael Marth |
Hi,
I didn't read all the details, but I think this is a promising approach.
Partitioning is flexible, so cluster nodes can be added and removed at
runtime without downtime. I believe we could use the 'virtual repository'
approach as the base for this implementation. That means, we first build a
RepositoryImpl attempts to close active session twice on shutdown
-
Key: JCR-3246
URL: https://issues.apache.org/jira/browse/JCR-3246
Project: Jackrabbit Content Repository
Hi,
Wouldn't this mean the NoSQL solution knows about hierarchy, and about our
revision model? I don't know about a NoSQL database that supports either
one. So, I don't currently see how this could work, except for trivial
cases (very flat hierarchy, only newest revision can be read).
Regards,
Hi,
I thinks this is a very important aspect to keep in mind. As I said
already [1], having inconsistencies on a given layer might result in
inconsistencies on upper layers. It is therefore important to have a
clear picture on what these inconsistencies are, how they propagate and
how to
Hi,
An open question though is how replication would fit into this picture.
There is some mention in the paper about backup nodes for fail-over. Not
sure if that is what we are aiming for or whether we want to go beyond
that.
I think what they use is a backup server, which is kept in sync
how does MVCC fit into this? multiple revisions of the same
JCR/MK node could be stored on a B-tree node. whenever
an update happens the garbage collection could kick in an
purge outdated revisions. providing a consistent journal across
all servers is not clear to me right now.
I think MVCC
Hi,
On Tue, Feb 28, 2012 at 11:13 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Let's have a quick poll on these at
http://www.doodle.com/zpnpmcv69pfaw73f. Please pick your favorites! If
a reasonable consensus emerges on one of the alternatives, then we'll
simply pick that one. Otherwise
Hi,
today I spent some time with a caching issue in my RepositoryService,
only to find out that the lifecycle of the service is not necessarily
the same as the one of the JCR2SPI RepositoryImpl.
See
public Session login(Credentials credentials, String workspaceName)
throws
On 01.03.2012, at 14:50, Michael Dürig wrote:
Nice to see new ideas wrt. to clustering. I quickly skimmed over the HP
paper and think that approach sounds promising. Having a flexible
partitioning scheme which also supports dynamic repartioning (i.e.
additions of server, migration of
23 matches
Mail list logo
