Using oscache 2.1rc1, I think I've stumbled upon a thread-safety issue with AbstractConcurrentReadCache's flushGroup method. Here's the exception:

2004-12-23 16:46:47,413 ERROR [GeneralExceptionHandler] An exception occurred:
java.util.ConcurrentModificationException
   at java.util.HashMap$HashIterator.nextEntry(HashMap.java:762)
   at java.util.HashMap$KeyIterator.next(HashMap.java:798)
   at java.util.AbstractCollection.addAll(AbstractCollection.java:315)
   at java.util.HashSet.<init>(HashSet.java:94)
   at com.opensymphony.oscache.base.algorithm.AbstractConcurrentReadCache.getGroup(AbstractConcurrentReadCache.java:380)
   at com.opensymphony.oscache.base.Cache.flushGroup(Cache.java:444)
   at com.opensymphony.oscache.base.Cache.flushGroup(Cache.java:431)
   at com.opensymphony.oscache.general.GeneralCacheAdministrator.flushGroup(GeneralCacheAdministrator.java:217)
   at com.bullionvault.site....

Looking at the source, this happens getGroup creates tries to copy a Set of groupEntries:

374
   375 if (groupEntries == null) {
   376 // Not in the map, try the persistence layer
   377 groupEntries = persistRetrieveGroup(groupName);
   378 } else {
   379 // We don't want to give them back the internal Set object
   380 groupEntries = new HashSet(groupEntries);
   381 }
   382
   383 return groupEntries;
   384 }

It seems that HashSet is iterating over groupEntries while they are being modified elsewhere. At least, that what the HashSet docs suggest:

" The iterators returned by this class's iterator method are
   /fail-fast/: if the set is modified at any time after the iterator
   is created, in any way except through the iterator's own remove
   method, the Iterator throws a ConcurrentModificationException."

I'm afraid don't know the code at all, so I can't offer a sensible patch.