Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Optimistic Concurrency Control - Reg. (This discussion is about Optimistic Concurrency Control technique implemented in CDO and how it can be customized to suit our needs.)
[CDO] Optimistic Concurrency Control - Reg. [message #1778093] Sat, 09 December 2017 20:18 Go to next message
Nirmal Kanagasabai is currently offline Nirmal KanagasabaiFriend
Messages: 9
Registered: July 2017
Junior Member
Hello Team,

I am working on persisting the models and model elements of our stand-alone client which runs on top of EMF to a database instead of the default XMI persistence. CDO was our obvious choice and I was able to establish a session, successfully open, commit & close transactions, persist and load resource to & from the database.

I am currently investigating the concurrency control techniques that CDO offers. I did come across the Documentation which talks about 'Collaboration in Real-Time' where both Optimistic and Pessimistic Concurrency Control techniques are discussed.

Our team (group of researchers) decided to go with Optimistic Concurrency Control instead of having locks. I understand the non-zero risk of commit conflicts. I was super impressed with 'Early Conflict Detection' and 'Automatic Conflict Resolution' and would definitely have them implemented.

Here's a couple of things which I wanted to get clarified about. I hope you can help me out on this regard:

1] Similar to Early Conflict Detection, Notifying the other collaborators about the model element one is currently working on. I mean to say, if three clients Client A, B and C are collaborating, if the particular model element that Client A is currently editing gets highlighted on both Client B and C, it's more like an early alarm and they would be warned to not edit/delete it to avoid conflicts.

As far as I know, if and only if a commit is made, the other collaborators are notified about it (which is the case of Early Conflict Detection). But, something like 'Google Docs' or 'Draw.io' where the element (which currently gets edited) being highlighted would be a cool addition. I have attached an image (Query1.png) which illustrates the functionality I described above for your reference.

Is there any way this could be implemented? Can you please provide me with some pointers on the same?

2] The second question would be about the 'CDO Collaboration View'. I understand that I will be able to send a short message to the selected user. - Is there anyway I could multicast it? (instead of listing down all connected users and iterating through it)
- Also, instead of a 'short message', will we be able to send any other information? Like, a model element?

Right now, I am clueless if there already exists something which does the same and I have overlooked it or if these could actually be achieved. I humbly request your assistance on this regard.

Looking forward to your reply.

Regards,
Nirmal
  • Attachment: Query1.png
    (Size: 379.46KB, Downloaded 25 times)
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778123 is a reply to message #1778093] Mon, 11 December 2017 05:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6345
Registered: July 2009
Senior Member
Hi Nirmal,

ad 1] Lock notification is already supported. Just do this:

  CDOView view = session.openView();
  view.options().setLockNotificationEnabled(true);
  view.addListener(new IListener()
  {
    public void notifyEvent(IEvent event)
    {
      if (event instanceof CDOViewLocksChangedEvent)
      {
        CDOViewLocksChangedEvent e = (CDOViewLocksChangedEvent)event;
        // ...
      }
    }
  });


ad 2] Multicast is already supported. Just do this:

  CDOSession localSession = getSession();
  CDORemoteSessionManager remoteSessionManager = localSession.getRemoteSessionManager();
  CDORemoteSession[] remoteSessions = remoteSessionManager.getRemoteSessions();
  remoteSessionManager.sendMessage(message, remoteSessions);


Also, you can define your own message types, see CDORemoteSessionMessage.getType(). The message data is just a byte array, so you can implement your message handler such that it decodes that data according to your message type.
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778124 is a reply to message #1778123] Mon, 11 December 2017 05:24 Go to previous messageGo to next message
Nirmal Kanagasabai is currently offline Nirmal KanagasabaiFriend
Messages: 9
Registered: July 2017
Junior Member
Hello Eike,

Thank you very much for the prompt reply.

1] I understand that Lock Notification is already supported. I did try it out using the CDO UI explorer you shipped. However, we decided not to use Locking techniques in our application which is exactly why I wanted to know more about notifying the other collaborators on which model element one is currently working on. The .png file I attached would clearly explain what functionality I am expecting.

2] Thank you very much for addressing this question as well. I will definitely investigate more on the code snippet that you provided for multicast. I will get back to you in case of any further clarifications.

Regards,
Nirmal
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778320 is a reply to message #1778124] Wed, 13 December 2017 06:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6345
Registered: July 2009
Senior Member
Sorry, I missed that picture. The CDO server just sees (explicit) locks and commits, so, what you have in mind is not possible out of the box. But you could use a combination of CDOTransactionHandler and a custom remote message protocol, like so:

    final CDOSession session = openSession();
    CDOTransaction transaction = session.openTransaction();
    transaction.addTransactionHandler(new CDODefaultTransactionHandler()
    {
      @Override
      public void modifyingObject(CDOTransaction transaction, CDOObject object, CDOFeatureDelta featureChange)
      {
        sendMessage("com.foo.modifyingObject", object.cdoID().toURIFragment().getBytes());
      }

      @Override
      public void committedTransaction(CDOTransaction transaction, CDOCommitContext commitContext)
      {
        sendMessage("com.foo.committedTransaction", null);
      }

      @Override
      public void rolledBackTransaction(CDOTransaction transaction)
      {
        sendMessage("com.foo.rolledBackTransaction", null);
      }

      private void sendMessage(String type, byte[] data)
      {
        CDORemoteSessionMessage message = new CDORemoteSessionMessage(type, data);
        CDORemoteSessionManager remoteSessionManager = session.getRemoteSessionManager();
        remoteSessionManager.sendMessage(message, remoteSessionManager.getRemoteSessions());
      }
    });
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778381 is a reply to message #1778320] Wed, 13 December 2017 15:52 Go to previous messageGo to next message
Nirmal Kanagasabai is currently offline Nirmal KanagasabaiFriend
Messages: 9
Registered: July 2017
Junior Member
Great! Thank you very much Eike. I will definitely try this out and will reach out to you in case I am stuck anywhere.
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778390 is a reply to message #1778381] Wed, 13 December 2017 17:32 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6345
Registered: July 2009
Senior Member
Also note that (without explicit locks) there can be multiple users (i.e., transactions) editing an object at the same time!
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778391 is a reply to message #1778390] Wed, 13 December 2017 17:36 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6345
Registered: July 2009
Senior Member
Oh, and also note that, as long as the server doesn't store protocol-specifi state (such as the set of users that edit an object), you can't be sure that you received all relevant messages. It would be possible that you subscribe to that modification notification "service" at a point in time when some objects are already in dirty state somewhere.
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778392 is a reply to message #1778391] Wed, 13 December 2017 17:53 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6345
Registered: July 2009
Senior Member
The more I think about it, the more I get the impression that any reliable solution wouldn't differ substantially from our existing explicit locking mechanism. You absolutely need server state and synchronous signalling between clients and server, or you risk to miss important editing information.
Re: [CDO] Optimistic Concurrency Control - Reg. [message #1778397 is a reply to message #1778392] Wed, 13 December 2017 19:31 Go to previous message
Nirmal Kanagasabai is currently offline Nirmal KanagasabaiFriend
Messages: 9
Registered: July 2017
Junior Member
Thank you very much Eike. I am overwhelmed by your commitment in responding to the query! I cannot thank you enough.
Being a newbie, I might take a while to understand what has been stated above. Nevertheless, a big respect to your support!
Previous Topic:[Xcore] Default value for multi-valued enum attributes
Next Topic:Attribute with HTML Content
Goto Forum:
  


Current Time: Mon Jan 22 12:46:34 GMT 2018

Powered by FUDForum. Page generated in 0.02407 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software