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.
Difference between revisions of "CDO/Legacy Mode"
(→Switch me on) |
(→Switch me on) |
||
| (31 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= Advantages = | = 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. | + | The most obvious advantage of the legacy mode is that you don't not need to [[Preparing_EMF_Models_for_CDO|convert your model]] and to regenerate your classes. This is very useful if you e.g. cannot change the source because you only own the binaries. In this case legacy mode is the best choice. |
= Drawbacks = | = Drawbacks = | ||
| − | The disadvantage of the legacy mode lies in its nature | + | The disadvantage of the legacy mode lies in its nature, it is just a minimal bridge between EMF and the CDO framework. Thus it inherits the limited scalability of "normal" EMF implementations. This means that legacy support does not support lazy loading or unloading. It is also a bit slower than the native CDO approach. See the [[CDO_Legacy_Mode#Performance|chapter]] about performance for more information. |
= Switch me on = | = Switch me on = | ||
| − | + | '''Important note: As of CDO 4.2 (M6) the legacy mode is always on and cannot be turned off!''' The following section only applies to older CDO versions: | |
| − | The | + | |
| + | The legacy mode is configurable per view and '''turned off''' by default. To switch legacy support on or off you can refer to static methods in CDOUtil. This will influence the setting for newly created CDOViews. Note that these methods are only setting the default behavior for the current thread. So you must ensure that yout set the flag for the right thread. | ||
| − | + | <source lang="java"> | |
| + | boolean CDOUtil.isLegacyModeDefault() | ||
| + | void CDOUtil.setLegacyModeDefault(boolean on) | ||
| + | </source> | ||
| − | + | The snippet below shows how legacy support can be enabled or disabled. | |
| − | + | ||
| − | The snippet below shows how legacy can be enabled or disabled. | + | |
<source lang="java"> | <source lang="java"> | ||
| − | + | CDOSession session = ...; | |
| − | ( | + | CDOTransaction transaction1 = session.openTransaction(); //this transaction is opened with no legacy support which is the default |
| + | |||
| + | CDOUtil.setLegacyModeDefault(true); | ||
| + | CDOTransaction transaction2 = session.openTransaction(); //this transaction is opened with legacy support | ||
| + | |||
| + | CDOUtil.setLegacyModeDefault(false); | ||
| + | CDOTransaction transaction3 = session.openTransaction(); //this transaction is opened with no legacy support again | ||
</source> | </source> | ||
| − | = | + | Additionally you can ask your view whether legacy mode is enabled for it by using the following method. |
| − | + | <source lang="java"> | |
| + | CDOView view = ...; | ||
| + | boolean isLegacy = view.isLegacyModeEnabled(); | ||
| + | </source> | ||
| − | + | Note, that you are not limited to use either native or legacy models. If you like you can combine both. It does not matter whether you reference from native to legacy or vice versa. | |
| − | + | =DynamicEObjects= | |
| + | Now it's possible to use DynamicEObjects on CDO. 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. Since 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. | ||
= 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 interested in the details of the test see org.eclipse.emf.cdo.tests.PerformanceTest. You can see that the difference between native and legacy it not that big. | + | 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 interested in the details of the test see [[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.cdo/tests/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/PerformanceTest.java?root=Modeling_Project&view=markup|org.eclipse.emf.cdo.tests.PerformanceTest]]. You can see that the difference between native and legacy it not that big. |
| + | |||
| + | The tests had been executed on a E6600 with ~3 GB RAM running on Windows XP SP2. MEMStore and JVM are used for redrucing the impact of the communication and the server leyer as much as possible. | ||
[[Image:CDO_legacy_native_performance.PNG|800px|center|]] | [[Image:CDO_legacy_native_performance.PNG|800px|center|]] | ||
| + | |||
| + | Surprisingly there is one case where legacy performs even better than the CDO native models. But this only applies if you are working with the objects before they are attached to a CDOResource. | ||
Latest revision as of 13:03, 19 March 2013
Advantages
The most obvious advantage of the legacy mode is that you don't not need to convert your model and to regenerate your classes. This is very useful if you e.g. cannot change the source because you 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 minimal bridge between EMF and the CDO framework. Thus it inherits the limited scalability of "normal" EMF implementations. This means that legacy support does not support lazy loading or unloading. It is also a bit slower than the native CDO approach. See the chapter about performance for more information.
Switch me on
Important note: As of CDO 4.2 (M6) the legacy mode is always on and cannot be turned off! The following section only applies to older CDO versions:
The legacy mode is configurable per view and turned off by default. To switch legacy support on or off you can refer to static methods in CDOUtil. This will influence the setting for newly created CDOViews. Note that these methods are only setting the default behavior for the current thread. So you must ensure that yout set the flag for the right thread.
boolean CDOUtil.isLegacyModeDefault() void CDOUtil.setLegacyModeDefault(boolean on)
The snippet below shows how legacy support can be enabled or disabled.
CDOSession session = ...; CDOTransaction transaction1 = session.openTransaction(); //this transaction is opened with no legacy support which is the default CDOUtil.setLegacyModeDefault(true); CDOTransaction transaction2 = session.openTransaction(); //this transaction is opened with legacy support CDOUtil.setLegacyModeDefault(false); CDOTransaction transaction3 = session.openTransaction(); //this transaction is opened with no legacy support again
Additionally you can ask your view whether legacy mode is enabled for it by using the following method.
CDOView view = ...; boolean isLegacy = view.isLegacyModeEnabled();
Note, that you are not limited to use either native or legacy models. If you like you can combine both. It does not matter whether you reference from native to legacy or vice versa.
DynamicEObjects
Now it's possible to use DynamicEObjects on CDO. 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. Since 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.
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 interested in the details of the test see [[1]]. You can see that the difference between native and legacy it not that big.
The tests had been executed on a E6600 with ~3 GB RAM running on Windows XP SP2. MEMStore and JVM are used for redrucing the impact of the communication and the server leyer as much as possible.
Surprisingly there is one case where legacy performs even better than the CDO native models. But this only applies if you are working with the objects before they are attached to a CDOResource.