[CDO] Object is unexpectedly non-writable [message #1796263] |
Tue, 09 October 2018 11:42 |
Robert Schulk Messages: 146 Registered: July 2015 |
Senior 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 |
|
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.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Re: [CDO] Object is unexpectedly non-writable [message #1796814 is a reply to message #1796802] |
Fri, 19 October 2018 10:51 |
Robert Schulk Messages: 146 Registered: July 2015 |
Senior 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 #1800856 is a reply to message #1800803] |
Wed, 09 January 2019 08:01 |
|
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?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.05278 seconds