|
Re: [CDO] CDOTransaction.close [message #998266 is a reply to message #998208] |
Wed, 09 January 2013 17:30 |
|
Am 09.01.2013 16:11, schrieb Andrew Whelan:
> Calling CDOTransaction.close when I am finished with a transaction is causing me some problems in threaded environment
> (RCP GUIs and such are involved).
Should I know about these problems?
> I noticed in a forum message that Eike Stepper said
>
> "Please note that CDO, by default, automatically and atomically releases all locks at commit time."
>
> Does this mean that call close() on a CDOTransaction is not necessary?
Not necessarily. An open transaction allocates more resources (both in client and server) than just locks.
But you don't need to close a transactions after each and every commit() call, if you're doing multiple commit() calls.
Think of a transaction as a JDBC connection with autoCommit==false: open, modify, commit, modify, commit, modify,
commit, close.
The close() of the session also closes all views/transactions.
> Also, are there any good examples of the CDOTransactionHandler objects?
Hmm, are the shipped implementing classes good enough? Hard to say what purpose you have in mind ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: [CDO] CDOTransaction.close [message #999272 is a reply to message #999266] |
Fri, 11 January 2013 17:41 |
|
Hi Andrew,
Each CDOObject is managed by a CDOView for the entire (local) lifetime. When the view is closed all objects managed by
that view become unusable. The same applies for objects managed by a CDOTransaction, which is a subtype of CDOView. You
must either keep the view/tx open until you no longer need to access the objects or copy the objects with
EcoreUtil.copy() before you close the view/tx.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 11.01.2013 18:33, schrieb Andrew Whelan:
> Hopefully the answer to this is easier than I think.
> Following is a code snippet that opens a transaction, gets data, commits. and closes the transaction.
> I have an active session object available called session. The following code is run.
> (System is a class that extends CDOObject).
> transaction = session.openTransaction();
> List<System> retList = new ArrayList<System>();
> try
> {
> CDOResource resource = transaction.getOrCreateResource(REPO);
> EList<EObject> list = resource.getContents();
> for(EObject obj : list)
> {
> System sys = (System)obj;
> retList.add(sys);
> }
> }
> catch(Exception e)
> {
> e.printStackTrace();
> }
> finally{
> if(transaction!=null)
> transaction.close();
> }
>
>
> I then take one of the System objects and load it into an RCP Editor application. Essentually I am accessing it.
> I get the following "Not active: Transaction" exception. I've been running into this alot. I have similar issues ("Not
> active: Transaction") when saving data. After the commit, I do a tranasaction.close in a finally clause.
> Do I have to have the transaction available to use and access the object as I would any other EMF EObject? Or is the
> code snippet above not blocking? Is there some CDO variable to check to see if it a tranaaction is complete?
>
> One of the times I recieved this was when the object was being accessed to see if it is a containment object. Does any
> one have any revelations for any of this (please!!!) or advice? Thanks!
>
> java.lang.IllegalStateException: Not active: Transaction 2 [MAIN]
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:87)
> at org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:194)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:178)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:943)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:592)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:514)
> at
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleEObject.dynamicGet(EStructuralFeatureImpl.java:2324)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1027)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
> at com.src.ewir.nighthawk.analysis.models.reference301.impl.ReferenceImpl.getSystemInformation(ReferenceImpl.java:313)
> at com.src.ewir.nighthawk.cdointerface.utils.ReferenceLabelProvider.getText(ReferenceLabelProvider.java:67)
> at org.eclipse.ui.dialogs.FilteredList.setElements(FilteredList.java:278)
> at
> org.eclipse.ui.dialogs.AbstractElementListSelectionDialog.setListElements(AbstractElementListSelectionDialog.java:178)
> at org.eclipse.ui.dialogs.ElementListSelectionDialog.createDialogArea(ElementListSelectionDialog.java:64)
> at org.eclipse.jface.dialogs.Dialog.createContents(Dialog.java:760)
> at org.eclipse.jface.window.Window.create(Window.java:431)
> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089)
> at org.eclipse.ui.dialogs.SelectionStatusDialog.create(SelectionStatusDialog.java:153)
> at
> org.eclipse.ui.dialogs.AbstractElementListSelectionDialog.access$superCreate(AbstractElementListSelectionDialog.java:445)
> at org.eclipse.ui.dialogs.AbstractElementListSelectionDialog.access$2(AbstractElementListSelectionDialog.java:444)
> at org.eclipse.ui.dialogs.AbstractElementListSelectionDialog$4.run(AbstractElementListSelectionDialog.java:456)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
> at org.eclipse.ui.dialogs.AbstractElementListSelectionDialog.create(AbstractElementListSelectionDialog.java:454)
> at org.eclipse.jface.window.Window.open(Window.java:790)
> at org.eclipse.ui.dialogs.AbstractElementListSelectionDialog.open(AbstractElementListSelectionDialog.java:440)
> at com.src.ewir.nighthawk.cdointerface.handlers.LoadFromDatabaseHandler.execute(LoadFromDatabaseHandler.java:60)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
> at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241)
> at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:829)
> at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:815)
> at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:805)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
> at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at com.src.ewir.nighthawk.platform.ui.Application.start(Application.java:20)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: [CDO] CDOTransaction.close [message #999461 is a reply to message #999364] |
Sat, 12 January 2013 06:24 |
|
Am 12.01.2013 00:03, schrieb Andrew Whelan:
> Ok, so if I do something like the following
>
> CDOTransaction transaction = session.openTransaction();
> CDOResource resource = transaction.getOrCreateResource(REPO);
This resource is already a CDOObject that requires the transaction to be open.
> EList<EObject> list = resource.getContents();
> I should not close the transaction. Correct?
Yes.
> In this case it may be wise to just make a EcoreUtils.copy of each.
That depends on your use case.
>
> In the case of creating a new object:
>
>
> SomeObject o = new SomeObject()//extends CDOObject
You probably *shouldn't* call the constructor. There's a generated XyzFactory you *should* use to create objects.
> CDOTransaction transaction = session.openTransaction();
> CDOResource resource = transaction
> .getOrCreateResource(REPO);
> resource.getContents().add(o);
> transaction.commit();
>
> Could I close the o.cdoView() or o.cdoView()? Looking at the javadocs for CDView I'm not really sure how the original
> CDOTransacion in the code above would be related to the o.cdoView()? Is it?
As I said, a CDOTransaction *is* a CDOView. In your case o.cdoView() returns that transaction. You may close it when you
no longer need to work with any of the objects that were created/managed by it.
You could roughly compare CDOView/CDOObject with sql.Connection/sql.ResultSet (more exactly a row in a result set).
Would you close the connection when you still need to work with a result set?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
Re: [CDO] CDOTransaction.close [message #1001648 is a reply to message #1001478] |
Thu, 17 January 2013 05:54 |
|
Am 16.01.2013 20:49, schrieb Andrew Whelan:
> The following is related to CDOTransaction.close so I am including it in this same thread. The line at the bottom of
> the following exception is where a CDOTransaction.close() occurs. Does this look like there is an associated object
> that is still being referenced by the application?
No, I doubt it.
> Is there a recommended way to find out from the CDOTransaction object if there are referenced objects that make
> closing dangerous?
Object references can only be browsed with a heap profiler or a Java 6 debugger.
> All CDOObjects are no longer needed at this point.
>
> BTW: The NullPointerException is due to a null InternalCDOViewSet in CDOResourceImpl.basicSetResourceSet.
Is there some way for me to reproduce this exception? Ideally you write a small test case. Examples:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/ResourceTest.java
Are you reusing your ResourceSet for multiple views?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> java.lang.NullPointerException
> at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.basicSetResourceSet(CDOResourceImpl.java:1347)
> at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$ResourcesEList.inverseRemove(ResourceSetImpl.java:604)
> at org.eclipse.emf.common.notify.impl.NotifyingListImpl.removeAll(NotifyingListImpl.java:945)
> at org.eclipse.emf.internal.cdo.view.CDOViewSetImpl.remove(CDOViewSetImpl.java:183)
> at org.eclipse.emf.internal.cdo.session.CDOViewContainerImpl.viewDetached(CDOViewContainerImpl.java:155)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doDeactivate(CDOViewImpl.java:1128)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.doDeactivate(CDOTransactionImpl.java:2247)
> at org.eclipse.net4j.util.lifecycle.Lifecycle.deactivate(Lifecycle.java:129)
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:221)
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:211)
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:237)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.close(AbstractCDOView.java:1332)
> at com.src.ewir.nighthawk.analysis.ui.editor2.editors.Editor.dispose(Editor.java:595)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] CDOTransaction.close [message #1006425 is a reply to message #998208] |
Thu, 31 January 2013 10:36 |
|
Hi Andrew,
then have you solved the problem?
I'm in same situation with a CDOView. When I try to close it, basicSetResourceSet for a CDO resource returns NullPointerException.
In fact, viewSet is null because getViewSet has notifier=org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain$AdapterFactoryEditingDomainResourceSet@d37bd8 resources=[CDOResource@OID2]
and the method returns null.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04276 seconds