[Mondrian] Mondrian cache sharing - Hacks and Proper Solutions (tm)

Julian Hyde jhyde at pentaho.com
Fri Aug 31 13:38:13 EDT 2012

I presume that most tools that use Mondrian (whether via the legacy API or olap4j) will accept an arbitrary connect string.

Are there any tools that build the connect string themselves, and therefore would not allow additional connect string parameters? I would be surprised. But if so, these tools would need to be fixed. If there are any tools that would need to be fixed, please shout now.

Where does that connect string come from? It usually comes from ome repository (e.g. Pentaho's connections, or I presume Saiku has a repository). But it might be in a properties file, or in primitive cases like JPivot hard-coded into a JSP page.

This new JdbcConnectionUuid would need to be set everywhere that the connect string is defined. If they are using a repository, this will just be one place.


On Aug 30, 2012, at 6:24 PM, Pedro Alves <pmgalves at gmail.com<mailto:pmgalves at gmail.com>> wrote:

As long as it works, fine by me.

Jpivot is the smallest issue, we can just remove the dynresolver part in pivot.jsp (we're doing it now with that spi anyway).

However, I'm worried about what I can't control.

Julian, how does that affect:

- Analyzer
- prd (cda uses prd libs, mondrian datasources)
- xactions

How could we make sure these would pass the correct property?

I'm not sure if all of them fall back to mondrianutils class. Would be simpler if so, though I have no idea if it passes all properties

 how can we define that property? I guess I could through context.xml, but not sure if thats the case with all the ways we can define dtasources in pentaho.

And... Maitaining a branch, please, anything but that....
- Hide quoted text -

On Friday, August 31, 2012, Julian Hyde wrote:
On Aug 30, 2012, at 5:47 PM, Paul Stoellberger <p.stoellberger at gmail.com<javascript:;>> wrote:

> I think thats a good approach in general. the only issues i see are how the api is used differently within the server:
> - jpivot passes a dynamicschemaprocessor, making the schema xml part of the key
> - mdxconnection doesnt pass along all parameters defined in darasources.xml
> - saiku passes the exact connection details from datasources.xml
> so if there is a jdbcconnectionuuid passed thats not ensuring that the catalog part is the same as well.

Divide and conquer. We've solved the connection part (as long as each client passes in the whole mondrian connect string, which shouldn't be hard to achieve).

Now the part that determines whether the schema XML is the same. Is it not sufficient to pass UseContentChecksum=true? Then all connections will end up with the same Md5 hash of their schema.

As an added bonus, we can print the connection UUID and the schema MD5 hash into the trace log. It should make it a lot easier to figure out whether different clients are getting the same cache instance.

> i understand your concern, but i'm not too convinced we can ensure that the same keys are used regardless in which environment mondrian is used.
> and its too bad there wont be a fix before next spring/summer... i guess we will have to maintan a branch ourselves then...

Please, no veiled threats to fork. I'm working with you guys.


Mondrian mailing list
Mondrian at pentaho.org<javascript:;>
Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20120831/3447d3be/attachment.html 

More information about the Mondrian mailing list