• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Not a Bug
  • interfaces
  • Reporter: hmak
  • March 04, 2009
  • 0
  • Watchers: 1
  • July 27, 2012
  • January 18, 2010

Attachments

Description

An autolock-ed method may throw following exception even if I acquire a lock (which happens to be an object other than “this”).

com.tc.object.tx.UnlockedSharedObjectException: ********************************************************************* Attempt to access a shared object outside the scope of a shared lock. All access to shared objects must be within the scope of one or more shared locks defined in your Terracotta configuration.

Caused by Thread: Thread-13 in VM(2) Shared Object Type: AutolockTest

The cause may be one or more of the following: * Terracotta locking was not configured for the shared code. * The code itself does not have synchronization that Terracotta can use as a boundary. * The class doing the locking must be included for instrumentation. * The object was first locked, then shared.

For more information on how to solve this issue, see: http://www.terracotta.org/usoe *********************************************************************

at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:355)
at com.tc.object.tx.ClientTransactionManagerImpl.fieldChanged(ClientTransactionManagerImpl.java:650)
at com.tc.object.TCObjectImpl.objectFieldChanged(TCObjectImpl.java:300)
at com.tc.object.TCObjectImpl.intFieldChanged(TCObjectImpl.java:340)
at AutolockTest.\_\_tc\_setm\_counter(AutolockTest.java)
at AutolockTest.unsafeMethod(AutolockTest.java:30)
at AutolockTest.access$0(AutolockTest.java:29)
at AutolockTest$1.run(AutolockTest.java:21) Exception in thread "Thread-13" com.tc.object.tx.UnlockedSharedObjectException:  \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Attempt to access a shared object outside the scope of a shared lock. All access to shared objects must be within the scope of one or more shared locks defined in your Terracotta configuration.

Caused by Thread: Thread-13 in VM(2) Shared Object Type: AutolockTest

The cause may be one or more of the following: * Terracotta locking was not configured for the shared code. * The code itself does not have synchronization that Terracotta can use as a boundary. * The class doing the locking must be included for instrumentation. * The object was first locked, then shared.

For more information on how to solve this issue, see: http://www.terracotta.org/usoe *********************************************************************

at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:355)
at com.tc.object.tx.ClientTransactionManagerImpl.fieldChanged(ClientTransactionManagerImpl.java:650)
at com.tc.object.TCObjectImpl.objectFieldChanged(TCObjectImpl.java:300)
at com.tc.object.TCObjectImpl.intFieldChanged(TCObjectImpl.java:340)
at AutolockTest.\_\_tc\_setm\_counter(AutolockTest.java)
at AutolockTest.unsafeMethod(AutolockTest.java:30)
at AutolockTest.access$0(AutolockTest.java:29)
at AutolockTest$1.run(AutolockTest.java:21)

Comments

Howard Mak 2009-03-04

Workaround: Refactor code so that object being lock has a new autolocked method

Tim Eck 2009-03-04

I’ll have to take a closer look. synchronized on “this” within the context of that run() method won’t do anything since that is the instance of the non-static inner class. But the nested synchronization on AutoLockTest.this should be your root object so the synchronization + autolocking run() should work.

Tim Eck 2009-03-04

It is subtle, but you need to include the Autolock$1 class for instrumentation. Changing your to this should do the trick:

<include>
  <class-expression>AutolockTest*</class-expression>
</include>

Lock expressions don’t mean anything if the target type is not included. A debatable policy for sure, but it is the current truth.

Howard Mak 2009-03-04

Thanks for poining out my error. Unfortunately, my original code [I distilled the reproduce case from] uses tim-annotations, and marking instrumented classes is trickier. And as far as I know there’s no way to annotation an anonymous inner class w/ @InstrumentedClass. :(

Howard Mak 2009-03-09

Clarification: This is no longer an issue for me