[Mondrian] Dimension member caching

Fri Aug 15 04:11:05 EDT 2008

Hari,

If you'd bothered to post the error stack it would have said something like
'no such method clearCache', and that would have saved everyone a lot of
time. The method was deprecated, and it was removed in 3.0.4 (see release
notes http://sourceforge.net/project/shownotes.php?release_id=596339
<http://sourceforge.net/project/shownotes.php?release_id=596339&group_id=353
02> &group_id=35302).

>From 3.0 onwards you need to use the CacheControl API. See
http://mondrian.pentaho.org/documentation/cache_control.php.

Julian

  _____  

From: Haridasan T [mailto:haridasan.t at gmail.com] 
Sent: Friday, August 15, 2008 12:59 AM
To: jhyde at pentaho.com; Mondrian developer mailing list
Subject: Re: [Mondrian] Dimension member caching

In the below case

<% mondrian.rolap.RolapSchema.clearCache(); %>  does not work with he 3.0
version of mondrian

How to clear Schema cache ?

<%@ page session="true" contentType="text/html; charset=iso-8859-1"
language="java"

import='java.sql.*, javax.sql.*,javax.naming.*'%>

<%@ page import="mondrian.rolap.*;" %>

<% mondrian.rolap.RolapSchema.clearCache(); %>

<%@ taglib uri="http://www.tonbeller.com/jpivot" prefix="jp" %>

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>

<jp:mondrianQuery id="query01" jdbcDriver="oracle.jdbc.driver.OracleDriver"
jdbcUrl="jdbc:oracle:thin:@192.168.1.101:1521:orcl" jdbcUser="nikilive"
jdbcPassword="nikilive" 

catalogUri="/WEB-INF/queries/FV_ADJUSTMENT_BI.xml">

select NON EMPTY {[Measures].[Total Adjustments],[Measures].[Total Sales]}
on columns, NON EMPTY 

{([Company].[All Company],[Year].[All Year],[Customer].[All Customer])} ON
rows from FV_ADJUSTMENT_BI

</jp:mondrianQuery>

<c:set var="title01" scope="session"><%=result0%></c:set>

<%connection0.close();%>

Thanks

Hari Nair

On 8/15/08, Julian Hyde <jhyde at pentaho.com> wrote: 

Test case?

  _____  

From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
Behalf Of Haridasan T
Sent: Thursday, August 14, 2008 9:13 PM
To: Mondrian developer mailing list

Subject: Re: [Mondrian] Dimension member caching

rolap.clearcache does not work with 3.0 of mondrian
It used to work with older versions
How to clear the cache using 3.0 of mondrian

On 8/14/08, michael.pflug at thomsonreuters.com
<michael.pflug at thomsonreuters.com> wrote: 

Thanks Mark.  After some more discussion we agree that the best way to
achieve our goal of never caching a dimension would not fall in line with
10788 because, as you pointed out, 10788 is intended to minimize dimension
table reads, not force them.  Our current thought is that we can implement a
new method in the CacheControl API that takes a hierarchy, gets a
MemberCacheHelper and calls MemberCacheHelper.flush() to flush the
appropriate hierarchy.  Does this sound like a valid solution?  

Thanks,

Mike

  _____  

From: Marc Berkowitz [mailto:marcb52 at speakeasy.net] 
Sent: Saturday, August 09, 2008 12:25 AM
To: Mondrian developer mailing list
Cc: Pflug, Michael (TH USA)
Subject: Re: [Mondrian] Dimension member caching

(I wrote this code -- and am still fixing it -- so I'll try to answer these
questions.)

michael.pflug at thomsonreuters.com wrote: 

I plan to utilize the dimension member caching feature implemented
with check in 10788 but I have a few questions I'm hoping the community
can help me out with before I get too far:   

1)  The feature is dependant on having the property
mondrian.rolap.EnableRolapCubeMemberCache=false, but I don't fully
understand the consequences of setting this property to false.  Can
anyone elaborate? 

This is a tricky point;  my own understanding may be warped, but I see it
like this:
Usually a schema defines dimension members by referring to a dimension
table. Mondrian creates a RolapMember object when it is needed, reading its
attributes from the dimension table. The resulting object is saved in a
cache so it can be found again, avoiding reading from the table again. The
cache also guarantees there is a unique RolapMember for each member, and the
cache has "indexes" to find related members (parent, children, level-peers)
in constant time. It is a soft cache - unused members can be dropped from
the cache for garbage collection -- 
and this is valid because should the member be needed again, it will just be
read from the table and put again into the cache.

This design assumes that the dimension table doesn't change. My new feature
helps deal with a dimension that changes in known small ways, letting an
application edit selected items in the cache, or flush them from the cache
to be reloaded with new values.

However, checkin 10203 of last november changed the cache design,
introducing a two level cache. The goal was to deal with shared members in a
shared dimension,  used by several cubes. Now a member is represented by
both a global RolapMember (for all cubes) and a local RolapCubeMember (one
for each relevant cube). 
The cache structure is much more complicated -- so it seemed risky to alter
it to add the new features. Therefore I implemented them to act on the
simpler, single level member cache.
The property EnableRolapCubeMemberCache was added so an application can
choose the old one-level cache (which supports my cache edits), or the newer
two-level cache
(which does not, but offers the advantages of checkin 10203). I assume that
10203 pays off for shared dimensions, and has no advantage otherwise.

2)  In the unit test MemberCacheControlTest.testDeleteCommand(), the
test allows two possible outcomes - one that flushes only the desired
member and one that flushes the entire level.  Walking through the test
it always seems to flush the entire level which is arguably less
desirable. Does anyone understand this behavior?  

Flushing more than requested is certainly sub-optimal, but strictly speaking
it's not incorrect, since mondrian might flush the member cache
spontaneously to reclaim space.

3)  The code specifically does not allow flushing of parent-child
dimensions and, as luck would have it, the dimension I am most
interested in flushing is parent-child.  There is no comment as to why
parent-child isn't allowed - can anyone fill me in on what the
difficultly might be in implementing this?

I avoided parent/child hierarchies because they have a more complex
structure in the member cache. The existing design of member-cache edits
might accommodate them, or it might require a complete rewrite. I'd have to
try it and see.  However I think a refactoring of the member cache is likely
in the near term, so it seems easier and maybe faster to wait for that,
rtsher than do a rewrite.

4)  Finally, my specific use case is that I have a volatile dimension
that I wish never to be cached.  I could clear the cache manually before
each query, but I'd rather specify an optional property in my schema
telling Mondrian to never cache the dimension.  Does anyone have any
objections to that implementation

No, but that's a different goal to  10788, which is intended to minimize
dimension table reads, not force them.
And it seems useful and (probably) simpler to implement than
member-cache-edits!

_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian

_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20080815/77ae8fc0/attachment.html 