Home » Modeling » EMF » [CDO] Exception when in an observable. (Databinding).
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687044 is a reply to message #687042] |
Wed, 25 May 2011 09:52   |
|
Am 24.05.2011 22:03, schrieb Christophe Bouhier:
> Hi, I get below exception, which is triggered from a databing observable. Could it be a transaction which is closed (By bad programming) or perhaps a timeout of the transaction?
>
> The pattern, I use is to have a CDOView/Transaction created for each User Interface screen (A screen is a heavily customized ViewPart). When the screen is disposed, I close the CDOiew. When I reopen the screen, I create a new CDOView/Transaction. The CDOSession is kept open through the duration of the Application open/close cycle.
Are these screens used for editing, too? Or are they traditional ViewParts that just display data and make that data selectable so that you can trigger separate actions from there?
>
> I use one single resourceset, which is always consulted for resources
> which might be open, when not, I create a new resource.
You mean a single ResourceSet per CDOView or CDOTransaction, right?
I can just guess that your application (or one of the used higher frameworks) are holding pointers to EObjects that have originally been provided by a CDOView. These EObjects must not be used after the CDOView has been closed (deactivated).
Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thx.
>
> java.lang.IllegalStateException: Not active: Transaction 3
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
> at org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
> at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
> at org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
> at org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
> at org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
> at org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687045 is a reply to message #687044] |
Wed, 25 May 2011 09:59 |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Well all I can say is that we had problems already because the
core-databinding library is caching informations.
From the stack I assume the informations displayed are displayed in a
Tree which uses an IObservableMap.
Tom
Am 25.05.11 11:52, schrieb Eike Stepper:
> Am 24.05.2011 22:03, schrieb Christophe Bouhier:
>> Hi, I get below exception, which is triggered from a databing
>> observable. Could it be a transaction which is closed (By bad
>> programming) or perhaps a timeout of the transaction?
>>
>> The pattern, I use is to have a CDOView/Transaction created for each
>> User Interface screen (A screen is a heavily customized ViewPart).
>> When the screen is disposed, I close the CDOiew. When I reopen the
>> screen, I create a new CDOView/Transaction. The CDOSession is kept
>> open through the duration of the Application open/close cycle.
> Are these screens used for editing, too? Or are they traditional
> ViewParts that just display data and make that data selectable so that
> you can trigger separate actions from there?
>
>>
>> I use one single resourceset, which is always consulted for resources
>> which might be open, when not, I create a new resource.
> You mean a single ResourceSet per CDOView or CDOTransaction, right?
>
> I can just guess that your application (or one of the used higher
> frameworks) are holding pointers to EObjects that have originally been
> provided by a CDOView. These EObjects must not be used after the CDOView
> has been closed (deactivated).
>
> Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Thx.
>>
>> java.lang.IllegalStateException: Not active: Transaction 3
>> at
>> org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
>>
>> at
>> org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
>>
>> at
>> org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
>>
>> at
>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
>>
>> at
>> org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
>>
>> at
>> org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>
>> at
>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
>>
>> at
>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>
>>
|
|
| |
| Re: [CDO] Exception when in an observable. (Databinding). [message #687047 is a reply to message #687046] |
Wed, 25 May 2011 10:24 |
|
Am 25.05.2011 12:10, schrieb Christophe Bouhier:
>
>> You mean a single ResourceSet per CDOView or CDOTransaction, right?
>
> Yes, this is the code (Sorry indenting messed up). I feel I am still not at ease with the relations from CDOSession->CDOView/CDOTransaction->ResourceSet.
In CDO each ResourceSet can have (attached) a single CDOViewSet. One or more CDOViews or CDOTransactions can register with this CDOViewSet and thereby "manage" some of the resources in the associated ResourceSet. The normal case is one CDOView per CDOViewSet. Multiple CDOViews in a CDOViewSet are only allowed if they "point" to different repositories (through their CDOSessions). Repositories are different if they have different repository UUIDs. That means you can combine resources from different repositories into a single ResourceSet. If you want to commit changes from such a hetorogenous ResourceSet you may want to associate the CDOViewSet of the ResourceSet with a CDOXATransaction. You can register multiple CDOViewSets (i.e. ResourceSets) with a CDOXATranscation and commit them alltogether atomically.
>
> *****
>
> final CDOView[] views = this.getSession().getViews();
>
>
> // FIXME, we seem to have multiple views????
> // if(views.length > 1){
> // // How can we have multiple views??
A CDOSession can open multiple CDOViews that "look" at the same CDOBranchPoint or different ones.
> // throw new java.lang.IllegalArgumentException();
> // }
>
> for (int i = 0; i < views.length; i++) {
> final CDOView view = views[i];
> if (view.getResourceSet().equals(set)) {
> if( view.hasResource(res) ){
res== resource *path* ?
> final CDOResource resource = view.getResource(res);
> return resource;
> }
> // We haven't found this resource in the current view's set,
> // but we can't create a new transaction, so we have to see if the
> // the CDOView has a transaction.
> if(view instanceof CDOTransaction){
> CDOTransaction transaction = (CDOTransaction)view;
> CDOResource resource = transaction.getOrCreateResource(res);
> return resource;
> }
> }
>
> }
>
> // We don't have a view, so let's open one.
> final CDOTransaction transaction = getSession().openTransaction(set);
> final CDOResource resource = transaction.getOrCreateResource(res);
> return resource;
It seems that this resource may be read-only (if provided by a CDOView) or read-write (if provided by a CDOTransaction). But I must say the purpose of your method is not fully clear to me.
>
>
>>
>> I can just guess that your application (or one of the used higher
>> frameworks) are holding pointers to EObjects that have originally been
>> provided by a CDOView. These EObjects must not be used after the CDOView
>> has been closed (deactivated).
>
> Well, I dispose the composite, but perhaps I should explictly dispose the JFace Viewers holding the data binding?
Perhaps. I don't know many details about DataBinding.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
>>
>> Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>>
>>> Thx.
>>>
>>> java.lang.IllegalStateException: Not active: Transaction 3
>>> at
>>> org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
>>>
>>> at
>>> org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
>>>
>>> at
>>> org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>>
>>> at
>>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
>>>
>>> at
>>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>>
>>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687048 is a reply to message #687045] |
Wed, 25 May 2011 10:30 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 25-05-11 11:59, Tom Schindl wrote:
> Well all I can say is that we had problems already because the
> core-databinding library is caching informations.
>
Hi Tom, Yes I saw this bug report.
> From the stack I assume the informations displayed are displayed in a
> Tree which uses an IObservableMap.
>
Well this is a JFace table, I think the problem is actually gone now, as
I also needed to dispose an ObservablesManager, which was still holding
on to a AggregateValidationStatus, which was holding on to
BindingContext.getValidationStatusProviders();
Call this did the trick, when disposing the screen.
observablesMgr.dispose();
>> Are these screens used for editing, too? Or are they traditional
>> ViewParts that just display data and make that data selectable so that
>> you can trigger separate actions from there?
@Eike, I missed out on this question:
These screens are editable viewparts, implementing ISaveablePart2 and
various other facilities. I prefer Viewparts over Editorparts.
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687050 is a reply to message #687048] |
Wed, 25 May 2011 10:54 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
Yes it is curcial to always collect observables using an obervable
manager and disposing all of them when the view is gone!
Tom
Am 25.05.11 12:30, schrieb Christophe Bouhier:
> On 25-05-11 11:59, Tom Schindl wrote:
>> Well all I can say is that we had problems already because the
>> core-databinding library is caching informations.
>>
> Hi Tom, Yes I saw this bug report.
>
>
>> From the stack I assume the informations displayed are displayed in a
>> Tree which uses an IObservableMap.
>>
> Well this is a JFace table, I think the problem is actually gone now, as
> I also needed to dispose an ObservablesManager, which was still holding
> on to a AggregateValidationStatus, which was holding on to
> BindingContext.getValidationStatusProviders();
>
> Call this did the trick, when disposing the screen.
>
> observablesMgr.dispose();
>
>>> Are these screens used for editing, too? Or are they traditional
>>> ViewParts that just display data and make that data selectable so that
>>> you can trigger separate actions from there?
>
> @Eike, I missed out on this question:
> These screens are editable viewparts, implementing ISaveablePart2 and
> various other facilities. I prefer Viewparts over Editorparts.
>
|
|
| |
| Re: [CDO] Exception when in an observable. (Databinding). [message #687246 is a reply to message #687042] |
Wed, 25 May 2011 09:52 |
|
Am 24.05.2011 22:03, schrieb Christophe Bouhier:
> Hi, I get below exception, which is triggered from a databing observable. Could it be a transaction which is closed (By bad programming) or perhaps a timeout of the transaction?
>
> The pattern, I use is to have a CDOView/Transaction created for each User Interface screen (A screen is a heavily customized ViewPart). When the screen is disposed, I close the CDOiew. When I reopen the screen, I create a new CDOView/Transaction. The CDOSession is kept open through the duration of the Application open/close cycle.
Are these screens used for editing, too? Or are they traditional ViewParts that just display data and make that data selectable so that you can trigger separate actions from there?
>
> I use one single resourceset, which is always consulted for resources
> which might be open, when not, I create a new resource.
You mean a single ResourceSet per CDOView or CDOTransaction, right?
I can just guess that your application (or one of the used higher frameworks) are holding pointers to EObjects that have originally been provided by a CDOView. These EObjects must not be used after the CDOView has been closed (deactivated).
Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thx.
>
> java.lang.IllegalStateException: Not active: Transaction 3
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
> at org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
> at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
> at org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
> at org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
> at org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
> at org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
> at org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
> at org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
> at org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
> at org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687247 is a reply to message #687044] |
Wed, 25 May 2011 09:59 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Well all I can say is that we had problems already because the
core-databinding library is caching informations.
From the stack I assume the informations displayed are displayed in a
Tree which uses an IObservableMap.
Tom
Am 25.05.11 11:52, schrieb Eike Stepper:
> Am 24.05.2011 22:03, schrieb Christophe Bouhier:
>> Hi, I get below exception, which is triggered from a databing
>> observable. Could it be a transaction which is closed (By bad
>> programming) or perhaps a timeout of the transaction?
>>
>> The pattern, I use is to have a CDOView/Transaction created for each
>> User Interface screen (A screen is a heavily customized ViewPart).
>> When the screen is disposed, I close the CDOiew. When I reopen the
>> screen, I create a new CDOView/Transaction. The CDOSession is kept
>> open through the duration of the Application open/close cycle.
> Are these screens used for editing, too? Or are they traditional
> ViewParts that just display data and make that data selectable so that
> you can trigger separate actions from there?
>
>>
>> I use one single resourceset, which is always consulted for resources
>> which might be open, when not, I create a new resource.
> You mean a single ResourceSet per CDOView or CDOTransaction, right?
>
> I can just guess that your application (or one of the used higher
> frameworks) are holding pointers to EObjects that have originally been
> provided by a CDOView. These EObjects must not be used after the CDOView
> has been closed (deactivated).
>
> Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Thx.
>>
>> java.lang.IllegalStateException: Not active: Transaction 3
>> at
>> org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
>>
>> at
>> org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
>>
>> at
>> org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
>> at
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
>>
>> at
>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
>>
>> at
>> org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
>>
>> at
>> org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
>>
>> at
>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>
>> at
>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
>>
>> at
>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
>>
>> at
>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>
>> at
>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>
>> at
>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>
>>
|
|
| |
| Re: [CDO] Exception when in an observable. (Databinding). [message #687249 is a reply to message #687046] |
Wed, 25 May 2011 10:24 |
|
Am 25.05.2011 12:10, schrieb Christophe Bouhier:
>
>> You mean a single ResourceSet per CDOView or CDOTransaction, right?
>
> Yes, this is the code (Sorry indenting messed up). I feel I am still not at ease with the relations from CDOSession->CDOView/CDOTransaction->ResourceSet.
In CDO each ResourceSet can have (attached) a single CDOViewSet. One or more CDOViews or CDOTransactions can register with this CDOViewSet and thereby "manage" some of the resources in the associated ResourceSet. The normal case is one CDOView per CDOViewSet. Multiple CDOViews in a CDOViewSet are only allowed if they "point" to different repositories (through their CDOSessions). Repositories are different if they have different repository UUIDs. That means you can combine resources from different repositories into a single ResourceSet. If you want to commit changes from such a hetorogenous ResourceSet you may want to associate the CDOViewSet of the ResourceSet with a CDOXATransaction. You can register multiple CDOViewSets (i.e. ResourceSets) with a CDOXATranscation and commit them alltogether atomically.
>
> *****
>
> final CDOView[] views = this.getSession().getViews();
>
>
> // FIXME, we seem to have multiple views????
> // if(views.length > 1){
> // // How can we have multiple views??
A CDOSession can open multiple CDOViews that "look" at the same CDOBranchPoint or different ones.
> // throw new java.lang.IllegalArgumentException();
> // }
>
> for (int i = 0; i < views.length; i++) {
> final CDOView view = views[i];
> if (view.getResourceSet().equals(set)) {
> if( view.hasResource(res) ){
res== resource *path* ?
> final CDOResource resource = view.getResource(res);
> return resource;
> }
> // We haven't found this resource in the current view's set,
> // but we can't create a new transaction, so we have to see if the
> // the CDOView has a transaction.
> if(view instanceof CDOTransaction){
> CDOTransaction transaction = (CDOTransaction)view;
> CDOResource resource = transaction.getOrCreateResource(res);
> return resource;
> }
> }
>
> }
>
> // We don't have a view, so let's open one.
> final CDOTransaction transaction = getSession().openTransaction(set);
> final CDOResource resource = transaction.getOrCreateResource(res);
> return resource;
It seems that this resource may be read-only (if provided by a CDOView) or read-write (if provided by a CDOTransaction). But I must say the purpose of your method is not fully clear to me.
>
>
>>
>> I can just guess that your application (or one of the used higher
>> frameworks) are holding pointers to EObjects that have originally been
>> provided by a CDOView. These EObjects must not be used after the CDOView
>> has been closed (deactivated).
>
> Well, I dispose the composite, but perhaps I should explictly dispose the JFace Viewers holding the data binding?
Perhaps. I don't know many details about DataBinding.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
>>
>> Perhaps Tom Schindl has more experience with CDO and EMF DataBinding...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>>
>>> Thx.
>>>
>>> java.lang.IllegalStateException: Not active: Transaction 3
>>> at
>>> org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:72)
>>>
>>> at
>>> org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifecycle.java:190)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.view.AbstractCDOView.getStore(AbstractCDOView.java:176)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjectImpl.java:1019)
>>>
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectImpl.java:567)
>>> at
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.dynamicGet(CDOObjectImpl.java:489)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
>>>
>>> at
>>> org.eclipse.emf.databinding.EObjectObservableMap.doGet(EObjectObservableMap.java:97)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.map.ComputedObservableMap$1.handleSetChange(ComputedObservableMap.java:58)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.fireSetChange(DecoratingObservableSet.java:59)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet.handleSetChange(DecoratingObservableSet.java:97)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.DecoratingObservableSet$1.handleSetChange(DecoratingObservableSet.java:71)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>>
>>> at
>>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet.access$1(DetailObservableSet.java:1)
>>>
>>> at
>>> org.eclipse.core.internal.databinding.observable.masterdetail.DetailObservableSet$1.handleSetChange(DetailObservableSet.java:46)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.SetChangeEvent.dispatch(SetChangeEvent.java:61)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.ChangeManager.fireEvent(ChangeManager.java:119)
>>>
>>> at
>>> org.eclipse.core.databinding.observable.set.ObservableSet.fireSetChange(ObservableSet.java:67)
>>>
>>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687251 is a reply to message #687045] |
Wed, 25 May 2011 10:30 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 25-05-11 11:59, Tom Schindl wrote:
> Well all I can say is that we had problems already because the
> core-databinding library is caching informations.
>
Hi Tom, Yes I saw this bug report.
> From the stack I assume the informations displayed are displayed in a
> Tree which uses an IObservableMap.
>
Well this is a JFace table, I think the problem is actually gone now, as
I also needed to dispose an ObservablesManager, which was still holding
on to a AggregateValidationStatus, which was holding on to
BindingContext.getValidationStatusProviders();
Call this did the trick, when disposing the screen.
observablesMgr.dispose();
>> Are these screens used for editing, too? Or are they traditional
>> ViewParts that just display data and make that data selectable so that
>> you can trigger separate actions from there?
@Eike, I missed out on this question:
These screens are editable viewparts, implementing ISaveablePart2 and
various other facilities. I prefer Viewparts over Editorparts.
|
|
|
| Re: [CDO] Exception when in an observable. (Databinding). [message #687253 is a reply to message #687048] |
Wed, 25 May 2011 10:54 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
Yes it is curcial to always collect observables using an obervable
manager and disposing all of them when the view is gone!
Tom
Am 25.05.11 12:30, schrieb Christophe Bouhier:
> On 25-05-11 11:59, Tom Schindl wrote:
>> Well all I can say is that we had problems already because the
>> core-databinding library is caching informations.
>>
> Hi Tom, Yes I saw this bug report.
>
>
>> From the stack I assume the informations displayed are displayed in a
>> Tree which uses an IObservableMap.
>>
> Well this is a JFace table, I think the problem is actually gone now, as
> I also needed to dispose an ObservablesManager, which was still holding
> on to a AggregateValidationStatus, which was holding on to
> BindingContext.getValidationStatusProviders();
>
> Call this did the trick, when disposing the screen.
>
> observablesMgr.dispose();
>
>>> Are these screens used for editing, too? Or are they traditional
>>> ViewParts that just display data and make that data selectable so that
>>> you can trigger separate actions from there?
>
> @Eike, I missed out on this question:
> These screens are editable viewparts, implementing ISaveablePart2 and
> various other facilities. I prefer Viewparts over Editorparts.
>
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 08:20:33 GMT 2024
Powered by FUDForum. Page generated in 0.03383 seconds |
] 
Search
Help
Register
Login
Home
