Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Object is unexpectedly non-writable
[CDO] Object is unexpectedly non-writable [message #1796263] Tue, 09 October 2018 11:42 Go to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
We are using an older CDO version: 4.5.0

In rare cases, we have a problem with write access to a resource.
This is basically what we do:

* A CDOTransaction adds/removes elements from a list (e.g. contents of a CDOResource)
* A CDOView (other session) monitors this list (in our case, the list is the input for an SWT Jface TableViewer)

Now, sometimes elements cannot be removed because they are not writable.
I.e.: element.cdoPermission().isWritable() == false
A write lock can be obtained without any problem, but the isWritable flag is still false:
I.e.: element.cdoWriteLock().lock()

=> The problem only applies to the session with the transaction. All other sessions see the element as writable.
=> Closing and reopening the transaction does not help.
=> We observed that the element may be writable again after a longer period of time (sometimes minutes, sometimes not for 1 hour).
=> If no view monitors the list, the problem does not happen.


Does anybody know what could be going on? Could a new CDO version potentially fix this problem? Unfortunately, we are not able to migrate to a newer version right away, but it would be an option for the future.

[Updated on: Tue, 09 October 2018 12:12]

Report message to a moderator

Re: [CDO] Object is unexpectedly non-writable [message #1796802 is a reply to message #1796263] Fri, 19 October 2018 06:10 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
Locks and permissions are totally unrelated in CDO. The former are about concurrency, the latter are about security. Are you using an ISecurityManager? If so, with ObjectFilters or custom PermissionFilters?

Is your CDOView an audit view (i.e., with a historical timestamp? Why is the view opened on a different CDOSession than the CDOTransaction?

You could set a (logging) breakpoint in org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setPermission() to get clues about permission changes. I find it more likely that the revision of the object/element is replaced with another one (that has different permissions) rather than the permission of the same revision is modified. But both is technically possible.


Re: [CDO] Object is unexpectedly non-writable [message #1796803 is a reply to message #1796802] Fri, 19 October 2018 06:10 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
Can you reproduce the problem in a test case?

Re: [CDO] Object is unexpectedly non-writable [message #1796814 is a reply to message #1796802] Fri, 19 October 2018 10:51 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
>> Are you using an ISecurityManager? If so, with ObjectFilters or custom PermissionFilters?

We do use an ISecurityManager. The permissions that we use are only of type ResourceFilter.
Although the user for which the error occurs has full access rights. I.e.:
realm.getUser("Administrator").getRoles().add(realm.getRole("All Objects Reader"));
realm.getUser("Administrator").getRoles().add(realm.getRole("All Objects Writer"));
realm.getUser("Administrator").getRoles().add(realm.getRole("Resource Tree Reader"));
realm.getUser("Administrator").getRoles().add(realm.getRole("Resource Tree Writer"));


>> Is your CDOView an audit view (i.e., with a historical timestamp? Why is the view opened on a different CDOSession than the CDOTransaction?

The view is used by another application => another session. We open the view like this:
view = session.openView();                                           
view.options().addChangeSubscriptionPolicy(CDOAdapterPolicy.ALL);    
view.options().setLockNotificationEnabled(true);                     


>> You could set a (logging) breakpoint in org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setPermission() to get clues about permission changes. I find it more likely that the revision of the object/element is replaced with another one (that has different permissions) rather than the permission of the same revision is modified. But both is technically possible.

I did not completely understand this. Here is the stacktrace from the line in question, when the permission is unexpectedly read-only:

CDORevisionImpl(BaseCDORevision).setPermission(CDOPermission) line: 956	
CDOSessionImpl$Invalidation.addNewRevision(InternalCDORevision) line: 2155	
CDOSessionImpl$Invalidation.reviseRevisions() line: 2119	
CDOSessionImpl$Invalidation.doRun() line: 1974	
CDOSessionImpl$Invalidation(RunnableWithName).run() line: 46	
ExecutorWorkSerializer$1.run() line: 104	
ThreadPool(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1149	
ThreadPoolExecutor$Worker.run() line: 624	
Thread.run() line: 748



I will try to set up a test case for this.

[Updated on: Fri, 19 October 2018 10:52]

Report message to a moderator

Re: [CDO] Object is unexpectedly non-writable [message #1796850 is a reply to message #1796814] Fri, 19 October 2018 17:37 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
If you want to copy some useful lines of code for security tests some good places are these:

org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_417483_Test
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_399487_Test
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_422170_Test
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_501607_Test
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_418267_Test

Good luck ;-)


Re: [CDO] Object is unexpectedly non-writable [message #1796921 is a reply to message #1796850] Mon, 22 October 2018 09:54 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
Best way would be if I could build/test the cdo code myself.
Is there a how-to about the build process?

If I simply start a maven build of
http://git.eclipse.org/c/cdo/cdo.git
it fails to find http://download.eclipse.org/eclipse/updates/4.9-I-builds
Re: [CDO] Object is unexpectedly non-writable [message #1796966 is a reply to message #1796921] Tue, 23 October 2018 09:57 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
I regenerated and pushed the .target file. Please pull and try again. Does it work now?

Re: [CDO] Object is unexpectedly non-writable [message #1798218 is a reply to message #1796966] Wed, 14 November 2018 10:03 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
Thanks, the build did work fine now. Although, I am currently not able to reproduce the behavior in a simple test case. I will keep trying when I find the time ;).
Re: [CDO] Object is unexpectedly non-writable [message #1800803 is a reply to message #1798218] Tue, 08 January 2019 14:03 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
Okay, this problem is really hard to reproduce. So far, I was not able to create a test case.
But it does happen from time to time for us.

It seems like it happens in this case:
* Add an element to a list
* Remove an element from the same list before comitting
* Commit both changes

So e.g.
EList<SomeClass> theList = getList();
theList.add(someObject);
theList.remove(4);
//here "someObject" is still writable
transaction.commit();
//now "someObject" is read-only


Our current recovery strategy is to:
1. Open a separate session
2. Change a field of the object and commit
3. Change the field back to its original value and commit

=> Now everything is writable again.
Could there be a cleaner way for the recovery?
Re: [CDO] Object is unexpectedly non-writable [message #1800856 is a reply to message #1800803] Wed, 09 January 2019 08:01 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6433
Registered: July 2009
Senior Member
I fear I can't answer your question without a way to reproduce your problem.

Quote:
It seems like it happens in this case:
* Add an element to a list
* Remove an element from the same list before comitting
* Commit both changes


What does "It seems" mean? Sometimes? Always?

Quote:
EList<SomeClass> theList = getList();


What kind of list is that?

Quote:
Our current recovery strategy is to:
1. Open a separate session
2. Change a field of the object and commit
3. Change the field back to its original value and commit


A separate session (without committing through it) is not enough to clear the situation?


Re: [CDO] Object is unexpectedly non-writable [message #1800867 is a reply to message #1800856] Wed, 09 January 2019 09:34 Go to previous message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 51
Registered: July 2015
Member
Eike Stepper wrote on Wed, 09 January 2019 08:01

What kind of list is that?


It is simply a containment reference list. I attached the very short ecore that we use. In that case it is the Log=>Entries field.

Eike Stepper wrote on Wed, 09 January 2019 08:01

A separate session (without committing through it) is not enough to clear the situation?


The separate session immediately sees the correct state. But in order to recover the original session, we need to commit some change to the object.

Another approach which worked for me but is probably unsafe:

EList<SomeClass> theList = getList();
theList.add(someObject);
theList.remove(4);
transaction.commit();
if(!someObject.cdoPermission().isWritable()) {
    ((BaseCDORevision) someObject.cdoRevision()).setPermission(CDOPermission.WRITE);
}


Previous Topic:[CDO] CDOStoreUnorderedEList invalidates index of RemoveCommand during undo
Next Topic:copy an element
Goto Forum:
  


Current Time: Tue Jun 25 08:18:00 GMT 2019

Powered by FUDForum. Page generated in 0.02393 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top