Shared Queue Demo : Incorrect Lock usage.

Type: Bug
Status: Closed
Priority: 0 Showstopper
Resolution: Fixed
Component/s: Kit & Installation
Labels:

Assignee: juris
Reporter: ssubbiah
Created: February 09, 2007
Votes: 0
Watchers: 0
Updated:
July 27, 2012
Resolved:
February 20, 2007

Description

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

Comments

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