Oops, meant to say "...than contributions adding definitions." On Fri, Apr 4, 2008 at 4:00 PM, Greg Dritschler <[EMAIL PROTECTED]> wrote:
> Ramkumar, > > Sorry for the delay in responding. I think you are probably right that > CopyOnWriteArrayList is the way to go. Presumably there will be far more > contributions traversing the definitions (looking for policy sets etc) than > contributions adding to the contributions. So trading off a high penalty on > write for no penalty on traversal sounds like a good idea. The write > penalty could be mitigated by batching updates; i.e. instead of adding new > intents, policy sets, etc. to the lists one-by-one, collect them and make > one update to each list. > > Greg Dritschler > > > On Wed, Apr 2, 2008 at 5:56 AM, Ramkumar R <[EMAIL PROTECTED]> wrote: > > > Hi All, I am new to Tuscany Community, being interested in contributing > > and > > trying to catch up. Right now am going through the code to get a feel of > > it > > and the threading issue (as mentioned in > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html) > > seems > > to be something simple that I can fix to try a hand with Tuscany. > > > > > > > > Looking at the current implementation SCADefinitionsImpl.java uses java > > ArrayList to store the list of policy sets, intents, binding types etc. > > Possible solutions to this issue woule be to > > > > > > > > a) synchronize the methods that does the operations like clear/addAll OR > > > > b) replace the existing ArrayList with Vectors OR > > > > c) replace the existing ArrayList with CopyOnWriteArrayList (new with > > Java1.5) > > > > > > > > Option (a) seems to be a bad idea for me as it would lock the entire > > method, > > instead i would go for option (b) OR (c). > > > > > > > > Going for option (b), using Vectors OR Collections.synchronizedList > > synchronizes your list object. However, the iterators implemented in the > > java.util Collections classes are fail-fast, which means that if one > > thread > > changes a collection while another thread is traversing it through an > > Iterator, the next Iterator.hasNext() or Iterator.next() call will throw > > ConcurrentModificationException. If we have to prevent > > ConcurrentModificationException, we must lock the entire List while you > > are > > iterating by wrapping it with a synchronized block, which inturn is > > costly. > > > > > > > > Option (c) seems to be a good solution to the above problem, the > > CopyOnWriteArrayList class from util.concurrent (which will also appear > > in > > the java.util.concurrent package in JDK 1.5) is a thread-safe > > implementation > > of ArrayList that offers far better concurrency. Multiple reads can > > almost > > always execute concurrently, simultaneous reads and writes can usually > > execute concurrently, and multiple simultaneous writes can often execute > > concurrently. Also CopyOnWriteArrayList contains a mutable reference to > > an > > immutable array, so as long as that reference is held fixed, you get all > > the > > thread-safety benefits of immutability without the need for locking. > > > > > > > > I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me > > if > > this one is the right approach. > > -- > > Thanks & Regards, > > Ramkumar Ramalingam > > > >
