• Bug
  • Status: Closed
  • 0 Showstopper
  • Resolution: Fixed
  • Kit & Installation
  • juris
  • Reporter: ssubbiah
  • February 09, 2007
  • 0
  • Watchers: 0
  • July 27, 2012
  • February 20, 2007


Shared Queue demo’s use of locks is wrong. It mutates data under a certain lock and reads the data without grabbing the same lock. The mail that first pointed this problem is attached below.

================================================== Hi,

We have come across something in the example(Shared Queue) given in teracotta samples. We observed that in tc-config.xml a write log is specified for method( Worker.keepAlive() ) cause a new instance is being created in the method and assigned to the long variable( lastbeat ). But no lock is specified for the method( Worker.attempKill() ) which accesses the long variable( lastbeat). According to our understanding there should be read lock specified on the method( Worker.attempKill() ).

Kindly explain this point. Cause we have many getter methods in our root object and this point needs to be addressed.

Does teracotta internally take care of this.

Regards, Sachin


Fiona OShea 2007-02-12

Tim can you comment on whether we should fix locking.

Juris Galang 2007-02-20

Fixed on rev 1293 in the trunk branch.

Named lock with lock-level read on method Worker::expire() (was attemptKill()) - added in tc-config for the sharedqueue demo