• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • DSO:L1
  • teck
  • Reporter: teck
  • July 03, 2006
  • 0
  • Watchers: 1
  • September 06, 2013
  • September 06, 2013

Description

A while back we I added some code to deal with the fact separate transactions (ie. threads) in the same client might both reference the same “new” (as in new to DSO) object . In that case there will a race to commit the “new” object. The fix for that bug has a new bug in it. The new code determines who is the winner of the race, the winner is allowed to commit the object wholesale, the loser of the race only commits deltas they created after first referencing the new object. Committing that set of deltas is wrong since they might have occured before the time the first thread commits the state. In this case, the distributed state of the object will be inconsistent with the local state.

There is more than one way to fix this problem, and I think it’s even already being worked on. This item is just to make sure we track the issue.

Comments

Fiona OShea 2006-07-05

Assigning to Kirkham for now. If we have a fix in the near term (i.e. before the NTT fix release)_ we should fix this in the Judah branch and main

Steve Harris 2006-07-13

Did your last batch of changes fix this?

Saravanan Subbiah 2006-07-13

This was fixed by making VM wide txns instead thread local txns. But since that fix makes us lose txn atomicity, that fix was not pushed. So this bug is still lurking around.