Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Server replication mechanism
[CDO] Server replication mechanism [message #990163] Tue, 11 December 2012 08:31 Go to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Dear CDO enthusiasts,

I've got some questions related to the IRepositorySynchronizer mechanism
in CDO, in case you have advices before I start developping my own solution.

We are currently deploying a CDO-based software for our users.

The issue is that the users are located in a city, and the CDO server in
another one. In result, the performances (especially when loading
models) are not acceptable for the end-users, because of the poor
network. On another hand, when deploying the server in their city the
users are satisfied by the tool performances.

That is why I'm currently trying to set up a replication mechanism: we
would like to have a MASTER server in city A, and a CLONE (potentially
many clones) of this server in the city B (the users's city). This will
allow to improve performances especially when loading their models, as
users directly use the CLONE and hence networks requests are way faster.

I've played with the OfflineExampleClone, and it works very well : I'm
able to launch a MASTER repository and its corresponding CLONE, and
whether I'm commiting in the MASTER or the CLONE changes are propagated
to the other repository thanks to the IRepositorySynchronizer. Notice
that in our case, we do not want to provide offline-mode support : if
the MASTER connection breaks, the user will not be able to do anything.

However, I still have some issues to tackle before being able to use
this solution on our software:
1. Cross-repository locks :
With my current prototype, whether I'm locking elements on CLONE or
MASTER, locks are not propagated to the other repository. This is
problematic for us, as we rely on a fine-grained lock mechanism that
automatically locks modified elements to prevent from any conflict. We
do not want (expect if we have no other solution) to allow conflicts
that would be resolved through a merge tool.

In other words, I would like to implement a mechanism that makes sure
that we only allow to lock objects on the CLONE if it is possible to
also lock the same objects on the MASTER.

2. Remote changes integration
For the same reasons, we would like to be sure that changes made on the
master repository have been integrated before being able to lock elements.

For example :
- User 1 makes a modification on an element E1 of the MASTER repository
=> locks are taken on both the MASTER and the CLONE repository
- User 2 cannot change E1 as it is locked on both repositories
- User 1 commits his modifications => locks are released on both the
MASTER and the CLONE repository
- User 2 should not be able to make changes on E1 as long as the changes
made by User 1 have not been propagated to the CLONE

Do you have tips or reference documentation about how to implement those
2 mechanisms ?
To make things more difficult, the software depends on CDO 4.0.2, and
not the latest CDO version...

Best regards, and thank you very much for your help !
Alex
Re: [CDO] Server replication mechanism [message #990168 is a reply to message #990163] Tue, 11 December 2012 09:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 11.12.2012 09:31, schrieb Alex Lagarde:
> Dear CDO enthusiasts,
>
> I've got some questions related to the IRepositorySynchronizer mechanism in CDO, in case you have advices before I
> start developping my own solution.
>
> We are currently deploying a CDO-based software for our users.
>
> The issue is that the users are located in a city, and the CDO server in another one. In result, the performances
> (especially when loading models) are not acceptable for the end-users, because of the poor network. On another hand,
> when deploying the server in their city the users are satisfied by the tool performances.
>
> That is why I'm currently trying to set up a replication mechanism: we would like to have a MASTER server in city A,
> and a CLONE (potentially many clones) of this server in the city B (the users's city). This will allow to improve
> performances especially when loading their models, as users directly use the CLONE and hence networks requests are way
> faster.
That makes sense.

> I've played with the OfflineExampleClone, and it works very well :
Please have a look at http://thegordian.blogspot.de/2012/11/use-online-data-offline.html , too.

> I'm able to launch a MASTER repository and its corresponding CLONE, and whether I'm commiting in the MASTER or the
> CLONE changes are propagated to the other repository thanks to the IRepositorySynchronizer. Notice that in our case,
> we do not want to provide offline-mode support : if the MASTER connection breaks, the user will not be able to do
> anything.
>
> However, I still have some issues to tackle before being able to use this solution on our software:
> 1. Cross-repository locks :
> With my current prototype, whether I'm locking elements on CLONE or MASTER, locks are not propagated to the other
> repository. This is problematic for us, as we rely on a fine-grained lock mechanism that automatically locks modified
> elements to prevent from any conflict. We do not want (expect if we have no other solution) to allow conflicts that
> would be resolved through a merge tool.
IIRC., only locks of durable views are replicated.

>
> In other words, I would like to implement a mechanism that makes sure that we only allow to lock objects on the CLONE
> if it is possible to also lock the same objects on the MASTER.
I think that's what currently happens. Locking wouldn't make sense otherwise. Have a look at SynchronizableRepository.java:

@Override
public LockObjectsResult lock(InternalView view, LockType lockType, List<CDORevisionKey> revisionKeys,
boolean recursive, long timeout)
{
if (view.getBranch().isLocal())
{
return super.lock(view, lockType, revisionKeys, recursive, timeout);
}

if (getState() != ONLINE)
{
throw new CDOException("Cannot lock in a non-local branch when clone is not connected to master");
}

return lockThrough(view, lockType, revisionKeys, false, timeout);
}

>
> 2. Remote changes integration
> For the same reasons, we would like to be sure that changes made on the master repository have been integrated before
> being able to lock elements.
That's always the case for locked objects. The LockObjectResponse transfers the latest state/revision to the requesting
party.

>
> For example :
> - User 1 makes a modification on an element E1 of the MASTER repository => locks are taken on both the MASTER and the
> CLONE repository
> - User 2 cannot change E1 as it is locked on both repositories
> - User 1 commits his modifications => locks are released on both the MASTER and the CLONE repository
> - User 2 should not be able to make changes on E1 as long as the changes made by User 1 have not been propagated to
> the CLONE
>
> Do you have tips or reference documentation about how to implement those 2 mechanisms ?
> To make things more difficult, the software depends on CDO 4.0.2, and not the latest CDO version...
I think CDO 4.2 is a must-have when it comes to offline replication.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Best regards, and thank you very much for your help !
> Alex
Re: [CDO] Server replication mechanism [message #990217 is a reply to message #990168] Tue, 11 December 2012 13:13 Go to previous messageGo to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Le 11/12/2012 10:06, Eike Stepper a écrit :
> I think CDO 4.2 is a must-have when it comes to offline replication.

Do you think it's possible to use a CDO sever in 4.2 with clients using
CDO 4.0 ? I think it would cause problems if net4j protocols used in cdo
have evolved between 4.0 and 4.2...

In the SynchronizableRepository class under CDO 4.0.2, I do not see the
method LockObjectsResult lock(InternalView view, LockType lockType,
List<CDORevisionKey> revisionKeys, boolean recursive, long timeout), so
it's no surprise if the lock propagation does not work in CDO 4.0.

Thanks for your fast (as always) answer !
Alex
Re: [CDO] Server replication mechanism [message #990226 is a reply to message #990217] Tue, 11 December 2012 13:45 Go to previous messageGo to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Another question: while playing with the replication mechanism, I tried
to clone a remote server. I got the following exception :

org.eclipse.net4j.signal.RemoteException:
java.lang.IllegalStateException: Can only retrieve current version 4 for
OID1 - version requested was BranchVersion[Branch[id=0, name=MAIN], v3]
at
org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:139)
at
org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128)
at
org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:446)
at
org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:63)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I said to myself "of course this makes cense: the MASTER server I'm
trying to clone must not allow auditing, and my CLONE server does, so my
CLONE needs historical informations that my MASTER server did not keep".
However, by CLONE has exactly the same configuration as my MASTER, with
no auditing, no branching, and the same Mapping strategy. Does this
issue make cense to you ?

Best regards,
Alex
Re: [CDO] Server replication mechanism [message #990292 is a reply to message #990217] Tue, 11 December 2012 18:03 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 11.12.2012 14:13, schrieb Alex Lagarde:
> Le 11/12/2012 10:06, Eike Stepper a écrit :
> > I think CDO 4.2 is a must-have when it comes to offline replication.
>
> Do you think it's possible to use a CDO sever in 4.2 with clients using CDO 4.0 ? I think it would cause problems if
> net4j protocols used in cdo have evolved between 4.0 and 4.2...
No, that's not possible.

> In the SynchronizableRepository class under CDO 4.0.2, I do not see the method LockObjectsResult lock(InternalView
> view, LockType lockType, List<CDORevisionKey> revisionKeys, boolean recursive, long timeout), so it's no surprise if
> the lock propagation does not work in CDO 4.0.
Yes, lock replication had been added later by NoMagic.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Server replication mechanism [message #990293 is a reply to message #990226] Tue, 11 December 2012 18:05 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 11.12.2012 14:45, schrieb Alex Lagarde:
> Another question: while playing with the replication mechanism, I tried to clone a remote server. I got the following
> exception :
>
> org.eclipse.net4j.signal.RemoteException: java.lang.IllegalStateException: Can only retrieve current version 4 for
> OID1 - version requested was BranchVersion[Branch[id=0, name=MAIN], v3]
> at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:139)
> at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:128)
> at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:446)
> at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:63)
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
Is the most important part of the stack trace missing?

> I said to myself "of course this makes cense: the MASTER server I'm trying to clone must not allow auditing, and my
> CLONE server does, so my CLONE needs historical informations that my MASTER server did not keep". However, by CLONE
> has exactly the same configuration as my MASTER, with no auditing, no branching, and the same Mapping strategy. Does
> this issue make cense to you ?
For all replication scenarios all involved repositories must be in branching mode, which includes auditing.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Server replication mechanism [message #990403 is a reply to message #990293] Wed, 12 December 2012 10:08 Go to previous messageGo to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

> For all replication scenarios all involved repositories must be in
> branching mode, which includes auditing.

Noted, although I wonder why: if we want to create a CLONE that does not
have offline capabilities, then creating an offline branch is no longer
a requirement. Hence shouldn't we be able to create clones without
branching activated ? I'm just curious, nothing blocking for my use case
here.

I've got another question related to server replication :
what is the best way (if possible) to plug a conflict resolver (that
would for example always consider that MASTER is right if conflicts are
found between CLONE and MASTER) directly inside the CLONE Repository?

By the way, my first experiments clearly show that using one CLONE per
site instead of one central MASTER repository is really efficient : it
reduces model loading by 3 if I use the CLONE instead of the MASTER :)

Best regards,
Alex
Re: [CDO] Server replication mechanism [message #990452 is a reply to message #990292] Wed, 12 December 2012 14:55 Go to previous messageGo to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Yet another question :)

I've built a clone-capabable cdo server (by extending the
CDOServerApplication and adding synchronization capabilities similary to
the OfflineCloneExample), and when trying to clone an already existing
cdo repository I encounter a "Generated packages locally not
available..." exception.

It's true that my CLONE does not have the listed packages installed, but
it's not an issue for the MASTER (correct me if I'm wrong): if I commit
instances of new metamodels, then the metamodels are embedded inside the
CommitDATA so that the server can interpret them.

It seems that it is not the case for the CLONE repository : how could I
automatically copy new metamodels used in MASTER when
cloning/integrating commits? Is this the expected behavior or am I doing
something wrong ?


Best regards,
Alex
Re: [CDO] Server replication mechanism [message #990705 is a reply to message #990403] Thu, 13 December 2012 06:01 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 12.12.2012 11:08, schrieb Alex Lagarde:
>> For all replication scenarios all involved repositories must be in
>> branching mode, which includes auditing.
>
> Noted, although I wonder why: if we want to create a CLONE that does not have offline capabilities, then creating an
> offline branch is no longer a requirement. Hence shouldn't we be able to create clones without branching activated ?
> I'm just curious, nothing blocking for my use case here.
You're right. This scenario just hasn't been considered, yet. More exactly the kind of optimization specific to this
particular usage.

> I've got another question related to server replication :
> what is the best way (if possible) to plug a conflict resolver (that would for example always consider that MASTER is
> right if conflicts are found between CLONE and MASTER) directly inside the CLONE Repository?
Conflict resolution on the server-side, as any other kind of commit change set modification) is currently not possible
because the committing client wouldn't be informed about this fact and continue to use possibly stale data. It's mostly
a matter of the network protocol not being prepared for this situation. We could enhance that.

> By the way, my first experiments clearly show that using one CLONE per site instead of one central MASTER repository
> is really efficient : it reduces model loading by 3 if I use the CLONE instead of the MASTER :)
Yeah, I can well imagine.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Server replication mechanism [message #990706 is a reply to message #990452] Thu, 13 December 2012 06:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 12.12.2012 15:55, schrieb Alex Lagarde:
> Yet another question :)
>
> I've built a clone-capabable cdo server (by extending the CDOServerApplication and adding synchronization capabilities
> similary to the OfflineCloneExample), and when trying to clone an already existing cdo repository I encounter a
> "Generated packages locally not available..." exception.
>
> It's true that my CLONE does not have the listed packages installed, but it's not an issue for the MASTER (correct me
> if I'm wrong): if I commit instances of new metamodels, then the metamodels are embedded inside the CommitDATA so that
> the server can interpret them.
Correct for master servers.

> It seems that it is not the case for the CLONE repository : how could I automatically copy new metamodels used in
> MASTER when cloning/integrating commits? Is this the expected behavior or am I doing something wrong ?
This is one of the TODOs listed in SynchronizableRepository.java: All involved packages must be pre-registered, ideally
before the repo starts for the first time. See IRepository.setInitialPackages().

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Previous Topic:[TENEO] Lazy Loading with UML
Next Topic:[emf compare] compare two jface treeviewer model data
Goto Forum:
  


Current Time: Sat Dec 20 17:24:02 GMT 2014

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

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