• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • DSO:L1
  • interfaces
  • Reporter: wharley
  • July 31, 2008
  • 0
  • Watchers: 1
  • December 16, 2011

Attachments

  • wharley (2.00 k) application/x-zip-compressed Archive.zip

Description

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.

NOTE: The same problem exists for a similar pattern on arrays (and the test should be updated to cover this).

Comments