4 Replies Latest reply on Mar 1, 2013 8:44 AM by Friso V

    synchronizing between two ModeShape instances

    Friso V Newbie

      Hi all,

       

      I'm in a project where we want to get two (or more) ModeShape instances communicating with each other. Lets assume two where we'll call the first A and the second B. Now a subset of the documents in A need to be available to B (the intersection in the picture below). It's important that these documents are not shared physically, so each instance has it's own, unshared, storage. Both A and B are allowed to make changes to these documents, though every document is only editable by one system (either A or B) at a time.

      http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Venn_A_intersect_B.svg/220px-Venn_A_intersect_B.svg.png

      Assume a user has changed document x on ModeShape intance A. We want to get these changes to be reflected in ModeShape instance B. As only one of these systems has the right to write, an overwrite of data in B using data in A would be acceptible.

       

      Before I go off and write code that will do this, I want to check if there are any known solutions for this problem. Does anybody know any?

       

      Groeten,

       

      Friso

        • 1. Re: synchronizing between two ModeShape instances
          Randall Hauch Master

          Is it true that you do not want to create a single cluster containing A and B?

           

          If not, then there's nothing out-of-the-box that will tie the two ModeShape instances together. Federation could be set up to do that, but we don't yet have a ModeShape connector (we do want one; see MODE-1718; any interest in working on it?). You could use a file-system connector, but that might not be the most natural.

           

          Part of the challenge is how each ModeShape instance will define the set of documents to be shared? Is it as simple as a single workspace or a subset of the hierarchy in a workspace?

          1 of 1 people found this helpful
          • 2. Re: synchronizing between two ModeShape instances
            Friso V Newbie

            Correct, I do not want to create a single cluster (A and B might each have their own cluster though). The solution doesn't need to be free or ModeShape specific (i.e. any commercial JCR sync tool might work).

             

            I've been thinking about connectors myself, but the way I see it (and please correct me if I'm wrong) I'd need a 'forking connector' where one child actually save the information to the current JCR and the other child sends the information to (a number of) other JCR's. Problem I see with that is that my 'transactionality' is not how I'd like it to be. I don't want to wait for other systems to have finished saving untill I can say session.save(), due to network latency, possible slowness of other systems etc.

            • 3. Re: synchronizing between two ModeShape instances
              Randall Hauch Master

              I've been thinking about connectors myself, but the way I see it (and please correct me if I'm wrong) I'd need a 'forking connector' where one child actually save the information to the current JCR and the other child sends the information to (a number of) other JCR's.

               

              Whether or not you need a "forking connector" depends entirely on how the documents are structured in the repository that contains a connector. For example, if all the documents under a certain path or paths were forwarded to a particular (external) repository, then you could use federation and a simple connector. Federation can "projection" an external source into multiple locations within the current repository, but everything below those paths are considered federated and owned by the one external source.

               

              If you're sending a particular document to multiple other repositories, then you'll definitely need some special logic. That's beyond the scope of our federation feature.

               

              Of course, because the JCR API and JSR-283 specification are scoped to just a local API, it would be up to the connector to handle the communication with the presumably remote repositories.

               

              Problem I see with that is that my 'transactionality' is not how I'd like it to be. I don't want to wait for other systems to have finished saving untill I can say session.save(), due to network latency, possible slowness of other systems etc.

               

              It is possible for a connector to be XA-aware by registering with the local transaction manager an XAResource for the remote system. There is nothing ModeShape does out-of-the-box, but it is possible.