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 no
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 LoginExceptio
Hi,
On Tue, Feb 28, 2012 at 11:13 AM, Jukka Zitting 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 we'll have a followup
Hi,
It looks my initial attempt at this didn't work too well, as my
intention wasn't clear enough and the interface draft I included
seemed to raise mostly concerns about technicalities (too many
methods, etc.) instead of the fundamental design tradeoffs I was
trying to highlight. So let's try thi
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 is
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
Vector clocks seem to not work well in systems with dynamic number of
participants, a problem that is adressed by Interval Tree Clocks [1] and [2].
[1] https://github.com/ricardobcl/Interval-Tree-Clocks
[2] http://gsd.di.uminho.pt/members/cbm/ps/itc2008.pdf
On Feb 29, 2012, at 3:38 PM, Michael D
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 han
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,
Th
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
Issu
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
s
On Thu, Mar 1, 2012 at 2:53 PM, Michael Marth 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 | Engineeri
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, D
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 f
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 node
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,
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 a
Hi,
On 3/1/12 11:18 AM, "Felix Meschberger" 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
>better im
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 w
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
> > 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
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
> 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
> 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
25 matches
Mail list logo