|[CDO] Converting existing code to use CDO and the transaction API [message #1690512]
||Fri, 27 March 2015 17:32
| Simon Goodall
Registered: July 2009
I am looking to change our application to use CDO from .xmi files and have a few questions on how to implement the change correctly. (Note I have not converted my data models to extend CDOObject and using CDO 4.3).
Some background: Each of our data files are stored in an .xmi file and are (currently) self contained. We also have another EMF model representing the logic organisation of data files and stores transient references to the loaded data model instances. When a data file is created or deleted, a corresponding element is created or removed in the logical data model. When a data file is loaded, the transient reference is set.
Currently each data file and the logical model are loaded into separate ResourceSets, each with their own command stack and can be saved independently.
Now I have configured an embedded CDO server in my rcp product. I create a single session instance. For my logical model I call session.openTransaction() and call transaction.commit() in an EContentAdapter whenever a change to the model is made.
For my data files, I again call session.openTransaction(), then transaction.getOrCreateResource() to obtain a resource. When I save I call resource.save() and transaction.commit(). Transactions are closed when I unload the resource. To delete a data file, I first unload (and close any previous transaction) and create a new transaction and get a resource by transaction.getResource() followed by resource.delete() & transaction.commit().
Is this the correct way to use the API? I am currently seeing various problems when running with the above model. When I set ENSURE_REFERENTIAL_INTEGRITY to true, I get lots of commit timeouts. When it is false, I end up with CDO stale reference exceptions, even after restarting the application (including CDO server).
Please let me know if you need more detail anywhere.
Powered by FUDForum
. Page generated in 0.03137 seconds