Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDO/Legacy Mode"

< CDO
(Performance)
(Performance)
Line 57: Line 57:
 
= Performance =  
 
= Performance =  
  
Due to its nature legacy mode is slower than the native approach. But have in mind that the loss of performance only applies to the client site. For the communication and the server side legacy is transparent. The graph below shows some simple performance measurements between native and legacy. If you are imterested in the details of the test see org.eclipse.emf.cdo.tests.PerformanceTest. Youcan see that the difference between native and legacy it not that. Surprisingly in one case legacy performs even better than the CDO native models. But only applies if you work with the objects before they are added to a resource. In this case CDO native objects (even generate) behave similar to dynamic objects. Compared to the generated EObjects this it certainly not that fast. But this advantage is lost whne the objects are attached to a resource.
+
Due to its nature legacy mode is slower than the native approach. But have in mind that the loss of performance only applies to the client site. For the communication and the server side legacy is transparent. The graph below shows some simple performance measurements between native and legacy. If you are imterested in the details of the test see org.eclipse.emf.cdo.tests.PerformanceTest. Youcan see that the difference between native and legacy it not that. Surprisingly in one case legacy performs even better than the CDO native models. But only applies if you work with the objects before they are added to a resource. In this case CDO native objects (even generate) behave similar to dynamic objects. Compared to the generated EObjects this it certainly not that fast. But this advantage is lost when the objects are attached to a resource.
  
 
[[Image:CDO_legacy_native_performance.PNG|800px|center|]]
 
[[Image:CDO_legacy_native_performance.PNG|800px|center|]]

Revision as of 14:51, 29 March 2010

Advantages

The most obvious advantage of the legacy mode is that you don not need to convert your model and to regenerate your classes. This is very useful if you e.g. cannot change the source because only own the binaries. In this case legacy mode is the best choice.

Drawbacks

The disadvantage of the legacy mode lies in its nature. It is just a bridge between EMF and the CDO framework. Thus it inherits the limited scalability of “normal” EMF implementations. It is also a bit slower than the native CDO approach. See the chapter about performance for more information.

Switch me on

We decided to make the legacy mode switchable. This has two reasons. First, native mode is always recommended. Use legacy objects only if you have not other chance. But then you should be aware of the disadvantaged. The second reason is the automatically attaching EObject to CDO could be harder to debug. Guess a user forgot to convert it’s model by accident and than receives an error which is related to legacy. This fact might not be show in the behaior of the error or even the stack trace of the exception. With a switchable legacy mode we can assure the user who are using legacy know what they do and that they are aware of using legacy.


From the technical point of view CDO now supports two ways to switch legacy support on or off. The first applies to the CDO session. If legacy is enabled fo a session all transactions on it are created legacy aware. To be exact, this flag also sets the behaviour of the session's transaction. By default legacy is disabled.

public interface InternalCDOSession extends CDOSession, PackageProcessor, PackageLoader, RevisionLocker, ILifecycle
{
 ...
 
  public void setLegacyEnabled(boolean legacyEnabled);
 
  public boolean isLegacyEnabled();
 
}


You can also switch legacy on or off on transaction level. The same methods are attached to the InternalCDOTransaction giving you the possibility to switch on certain transaction. You can also disable legacy integration for some transactions even if the session allows by default.

public interface InternalCDOSession extends CDOSession, PackageProcessor, PackageLoader, RevisionLocker, ILifecycle
{
 
 public void setLegacyEnabled(boolean legacyEnabled);
 
 public boolean isLegacyEnabled();
 
}

The snippet below shows how legacy can be enabled or disabled.

((InternalCDOSession)session).setLegacyEnabled(true);
((InternalCDOTransaction)transaction).setLegacyEnabled(true);

DynamicEObjects

While it was forbidden and punished with an exception to use DynamicEObjects on CDO this is now possible. You can create the dynamic objects as you are used to and store them in CDO. But remember that this is not the recommended way. Because dynamic EObjects can easily be converted to CDO you are encouraged to use CDOUtil.prepareDynamicEPackage(dynamicMapEPackage) whenever possible to convert your dynamic model to a CDO native one. For this reason the tracer, when activated, gives a warning if you have not done so.

Mixed Mode

You are not limited to use either native or legacy models. If you like you can combine both. This is then called the mixed mode. It does not matter whether you refernece from native to legacy or vice versa.

Performance

Due to its nature legacy mode is slower than the native approach. But have in mind that the loss of performance only applies to the client site. For the communication and the server side legacy is transparent. The graph below shows some simple performance measurements between native and legacy. If you are imterested in the details of the test see org.eclipse.emf.cdo.tests.PerformanceTest. Youcan see that the difference between native and legacy it not that. Surprisingly in one case legacy performs even better than the CDO native models. But only applies if you work with the objects before they are added to a resource. In this case CDO native objects (even generate) behave similar to dynamic objects. Compared to the generated EObjects this it certainly not that fast. But this advantage is lost when the objects are attached to a resource.

CDO legacy native performance.PNG

Back to the top