|[CDO] Critical issues with CDO Workspaces [message #1385478]
||Fri, 06 June 2014 18:49
| Josh M
Registered: July 2009
We are having some critical issues when trying to implement CDO workspaces given our current environment. I have been able to refine our problems so far into three separate issues:
- (1) The structure of our models causes critical issues with the repository package management,
- (2) Using a local H2 DB store appears not to work as we would expect, and
- (3) Improper CDOPackageUnit disposal (?)
We have been able to create two test cases that reproduce the first two problems, and those test cases and their respective console outputs are attached. Some notes on each:
- (1) Packages (Model4Test.java):
- (a) The stack trace below shows that an NPE is hit when trying to access the CDOPackageUnitImpl.packageInfos, which is null. Debugging shows that this CDOPackageUnitImpl is actually disposed at the time this exception occurs.
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
- (b) This problem was reproduced by mimicking org.eclipse.emf.cdo.tests.WorkspaceTest, but using Model4 instead of Model1. Only the testCheckout and testReadObjects methods were implemented.
- (2) Local DB Store (LocalDBStoreTest.java)
- (a) We will have the requirement that workspace checkout will persist between sessions, so the use of a local DB store instead of a Mem store seemed appropriate. Unfortunately, when org.eclipse.emf.cdo.tests.WorkspaceTest was extended to use a local DB Store, 6 of the 32 tests failed. The tests that failed were:
- (1) testCheckinAfterAddExt: IllegalStateException: PreparedStatement[sql=DELETE FROM CDORESOURCE WHERE CDO_ID=? , probability=HIGH, touch=142] returned Update count 0 (expected: 1)
- (2) testCheckinAfterModify2: IllegalStateException: PreparedStatement[sql=DELETE FROM PRODUCT1 WHERE CDO_ID=? , probability=HIGH, touch=126] returned Update count 0 (expected: 1)
- (3) testCheckin2AfterModify: AssertionFailedError: expected:<5> but was:<0>
- (4) testCheckin2AfterDetach: ObjectNotFoundException: Object _KdUQ9e2bEeOkg_Afry7_-A not found
- (5) testCheckinAfterAdd2: IllegalStateException: PreparedStatement[sql=DELETE FROM CDORESOURCE WHERE CDO_ID=? , probability=HIGH, touch=142] returned Update count 0 (expected: 1)
- (6) testCheckin2AfterAdd: CDOException: Cannot find revision with ID _Tx5ase2bEeOkg_Afry7_-A
- (b) The test class LocalDBStoreTest was built by extending WorkspaceTest. The method createLocalStore() was overridden to provide the local IDBStore, and the method doTearDown() was extended to delete all tables between tests.
- (3) Given the topic of package management, as well as the complexity of our models, we noticed some other issues that we do not yet have test cases for. However our investigation shows some additional behavior which we are not sure if is fully intended. The steps are as follows:
- (a) CDOWorkspaceImpl.checkout(): the packageUnits owned by the remote session's package registry are queried, and the attached to the local repository's package registry via InternalCDOPackageRegistry.putPackageUnits(InternalCDOPackageUnit, State).
- (b) CDOPackageRegistryImpl.putPackageUnit(InternalCDOPackageUnit): the CDOPackageUnit has its reference to InternalCDOPackageRegistry set to the local repository's package registry. It should be noted that the remote package registry still has a reference to this CDOPackageUnit via its packageUnits collection, or even more elusively, within its packageInfos collection, should a given CDOPackageInfo have a reference to this same CDOPackageUnit
- (c) Following a checkout, the remote session, and its internal package registry, is deactivated. This begins to dispose the package units, which are ultimately provided by CDOPackageRegistryImpl.collectPackageUnit(Object).
- (d) The CDOPackageUnits collected by this method can be discovered from one of 3 ways:
- (1) CDOPackageInfo.getPackageUnit()
- (2) Looking up the CDOPackageInfo from via CDOPackageRegistryImpl.get(nsURI) and then calling CDOPackageInfo.getPackageUnit()
- (3) Looking up the CDOPackageInfo from within CDOPackageRegistryImpl.packageInfoMap
- (e) Only #2 above actually checks to see that the CDOPackageUnit's package registry equals the same package registry that is being disposed, all other options do not perform this check
- (f) In the event that more than one CDOPackageInfo maps to the same CDOPackageUnit (which seems to occur with sub-packages), then its parent CDOPackageUnit will be disposed, even it has already been mapped to another package registry.
Any assistance you could provide to resolve these issues would be greatly appreciated. Please let us know if there is any other information that might be useful for us to provide in these matters.
Powered by FUDForum
. Page generated in 0.01361 seconds