If you are using a collection object to contain objects used for concurrent readonly access and you want read access to be fast you need to keep it simple.
Use an unsynchronized collection such as ArrayList or the one you are using (which is also a list and is also not thread safe). It is much faster for read access than a thread safe object such as Vector. For instance vector will block readers during an add operation, yours won't. If the iterators are only used to read object data it is better to replace the collection when you change its contents with a new collection object rather than modify its contents, in other words the collection should be immutable. Also, treat the objects in the collection as immutable as well. When you need to modify the collection create a new one and you can reference the objects in the old collection through its iterator and add, change or delete objects. Finally, once you have built the new modified collection object then change the exposed reference to the object (for instance a method that hands you the iterator to the collection). Anyone who is reading the iterator when you change the collection reference maintains their handle to the old collection object until they release their handle. Any new accessors will get the new object. I hope this helps. If you need concurrent access to a changeable collection object use Vector and pay the performance penalty, but usually the strategy I explained will outperform it for read only users. This technique is especially useful when you have a large number of reads for every write. Good luck --- "Baltz, Kenneth" <[EMAIL PROTECTED]> wrote: > I don't know anything about your specific situation, but I do know that > ConcurrentModificationExceptions can happen even in single-threaded > environments. The biggest culprit is changing the collection the iter is > based on while you're iterating. Remove(), add(), these are generally > forbidden and will cause this exception the next time next() is called. > > Hope that helps. > > K.C. > > > -----Original Message----- > > From: Lee Breisacher [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 28, 2003 9:32 AM > > To: [EMAIL PROTECTED] > > Subject: CursorableLinkedList ConcurrentModificationException > > > > > > I just ran into this error: > > > > java.util.ConcurrentModificationException > > at > > java.util.AbstractList$Itr.checkForComodification(AbstractList > .java:444) > > at java.util.AbstractList$Itr.next(AbstractList.java:421) > > at > > org.apache.commons.collections.CursorableLinkedList.broadcastL > > istableInserte > > d(Unknown Source) > > at > > org.apache.commons.collections.CursorableLinkedList.insertList > > able(Unknown > > Source) > > at > > org.apache.commons.collections.CursorableLinkedList.addFirst(U > > nknown Source) > > at > > org.apache.commons.pool.impl.GenericObjectPool.returnObject(Un > > known Source) > > > > Unfortunately, I do not have stack traces for the other > > threads that were > > running, so I don't know what some other thread must have > > been doing to > > cause this. But, looking at GenericObjectPool, it appears to > > be properly > > synchronized at all the places that operate on the > > CursorableLinkedList (its > > _pool variable), so I don't quite understand how this error can occur. > > Anyway, does this look like a bug in CursorableLinkedList? > > Has anyone seen > > this before and know of a fix/workaround? > > > > Thanks, > > > > Lee > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
