inconsistent shared object state after unlocked object exception
----------------------------------------------------------------
Key: CDV-822
URL: https://jira.terracotta.org/jira//browse/CDV-822
Project: Community Development
Issue Type: Bug
Components: DSO:L1
Affects Versions: 2.6.2
Reporter: Walter Harley
Assignee: Issue Review Board
Attachments: Archive.zip
Attempting to mutate a field of a shared object without an autolock will cause
an UnlockedSharedObjectException to be thrown. After this exception, the value
of the field will be null for all other viewers for which the field was
previously unresolved.
The following code snippet demonstrates the problem (see attached archive for
complete test code):
public void run() {
root = new A();
try {
// attempt to mutate without a shared lock
root.o = new Object();
} catch (Throwable t) {
// ignore unlocked object exception
}
Assert.assertNotNull(root.o);
}
In this snippet, the assertion will fail for all L1 clients for which the field
was unresolved, i.e., all but the first.
The reason for the bug is that in TCObjectImpl.objectFieldChanged, we call
clearReference() before calling ClientTransactionManager.fieldChanged(). If
fieldChanged() throws an exception, the reference has still been cleared, even
though the field was not actually set. If the field was previously unresolved,
it will now contain a null but there will be no reference; this condition is
identical to a "real" null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.terracotta.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
