[Mondrian] Improving concurrency on Segment.getCellValue()

Eric McDermid mcdermid at stonecreek.com
Tue Dec 2 07:41:01 EST 2008

On Dec 2, 2008, at 4:05 AM, Julian Hyde wrote:

> Another part of the life cycle you don't mention is Aggregation member
> List<Segment> segmentRefs, which is implemented using a
> CopyOnWriteArrayList. This ensures that looking up a Segment that  
> matches a
> particular cell value can be done without taking locks.

Hmmm... I did mention (and miscapitalize) segmentRefs, but must have  
dropped the note that it is a CopyOnWriteArrayList in a late edit.   

> Whatever solution you choose, it needs to work under JDK 1.4 using
> mondrian's current strategy based on retroweaver.

Absolutely.  Both primitives are part of the concurrency backport, so  
I think we're clear, but I will certainly double-check.

> My biggest concern is that the code will be another factor more  
> difficult to
> understand after your change. You will at the very least need to  
> document
> the locking strategy that you implement at an appropriate point in  
> the class
> documentation. Approach #2 is attractive because it reflects the  
> locking
> protocol in the class structure (first ascertain the state, then get  
> the
> data).

Unfortunately, it doesn't reflect the entire locking protocol in the  
class structure.  The immutable LoadedSegment in #2 helps us eliminate  
locking once everything has been fully constructed, but we still have  
to enforce locking within LoadingSegment up until that point.  This  
means we would still need to build (and document) a locking strategy  
very much like approach #1 within LoadingSegment.

The sense that #2 is very nearly a superset of the code required for  
#1 is what leads me to think #1 may be simpler for future maintainers  
to understand.  As you point out, though, it is also less work to  

> I am not going to mandate approach #2. As you say, it makes sense to  
> do
> option #1 first, and you should do that. I would like you to leave  
> deliver
> clear, maintainable code, and you should seriously consider option  
> #2 if it
> leads to clearer code.

Of course.

  -- Eric

More information about the Mondrian mailing list