Eclipse Community Forums: EMF » [CDO] Object is unexpectedly non-writable

Home » Modeling » EMF » [CDO] Object is unexpectedly non-writable

[CDO] Object is unexpectedly non-writable [message #1796263]

Tue, 09 October 2018 07:42

Eclipse User

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 08:12] by Moderator

Re: [CDO] Object is unexpectedly non-writable [message #1796802 is a reply to message #1796263]

Fri, 19 October 2018 02:10

Eclipse User

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 02:10

Eclipse User

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 06:51

Eclipse User

>> 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 06:52] by Moderator

Re: [CDO] Object is unexpectedly non-writable [message #1796850 is a reply to message #1796814]

Fri, 19 October 2018 13:37

Eclipse User

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 05:54

Eclipse User

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 05:57

Eclipse User

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 05:03

Eclipse User

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 09:03

Eclipse User

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 03:01

Eclipse User

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 04:34

Eclipse User

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);
}

Attachment: logspec.ecore
(Size: 1.34KB, Downloaded 148 times)

Previous Topic:	[CDO] Caching and explicit garbage collection
Next Topic:	copy an element

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 11:39:35 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter