race to commit newly shared objects referencing the same instrumented enum causes assertion in the L2 apply

Type: Bug
Status: Closed
Priority: 2 Major
Resolution: Fixed
Component/s: DSO:L1,DSO:L2
Labels:

Assignee: teck
Reporter: teck
Created: January 30, 2007
Votes: 0
Watchers: 0
Updated:
July 27, 2012
Resolved:
January 30, 2007

Description

Exception in thread “WorkerThread(apply_changes_stage,0)” com.tc.util.TCAssertionError: Expected <1> but got <0> at com.tc.util.Assert.assertEquals(Assert.java:135) at com.tc.objectserver.managedobject.LiteralTypesManagedObjectState.apply(LiteralTypesManagedObjectState.java:44) at com.tc.objectserver.managedobject.ManagedObjectImpl.apply(ManagedObjectImpl.java:158) at com.tc.objectserver.tx.ServerTransactionManagerImpl.apply(ServerTransactionManagerImpl.java:163) at com.tc.objectserver.handler.ApplyTransactionChangeHandler.handleEvent(ApplyTransactionChangeHandler.java:77) at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:141

Comments

Tim Eck 2007-01-30

The traverser for new shared objects will create TCObjects for literal instances referenced. That isn’t supposed to happen, but wasn’t causing a problem since ClientObjectManager never recorded the TCObject->pojo mapping (there is a isLiteralPojo() check in ClientObjectManager.basicAddLocal()). In this case, orphan TCObjects and corresponding state instances in the server were being created for non-primitive literals. When an enum class is instrumented (and more importantly acquires the Manageable interface), the code in basicAddLocal() does remember the TCObject mapping. This fact combined with racing txns leads one txn to dehydrate the literal, and the other to send a delta DNA containg zero actions, which produces the exception

Fix is change the traverser to not include literals.