[Mondrian] Mondrian's cache key is tied to the actual datasource.Is this right?

[Julian Hyde]

Thanks for bringing this up. This is an important issue we need to solve to
get olap4j working properly in the platform.

First of all, that method should be returning an ArrayList rather than doing
string comparisons. So for this discussion let's assume that that's the
case.

Then there's the important issue of when we consider two
javax.sql.DataSource objects to be equal.

The options that I can think of are:

0. (What we do now.) We assume they are equal only if they are the same
object. (identityHashCode has that effect.) That is extremely conservative,
and means that we do less caching than we could.

1. Regard data sources as equal if the values returned by their toString()
methods are the same.

2. Regard them as equal if their equals() and hashCode() methods say they
are.

3. If the data source is type that we know contains a JDBC connect string,
look into it and compare connect strings. If not, fall back on option 0, 1
or 2.

Problem is, I don't remember why we started using identityHashCode in the
first place. Maybe we'll break stuff. Or maybe, because we don't control how
a DataSource is implemented, we just don't trust them to have done a
sensible job with toString, equals or hashCode.

I am inclined to go for option #2. But I am still a bit worried that we'll
break stuff -- two data sources that are not the same will compare equal
because the data source implementor screwed up. And there will be cases
where we want two data sources to compare the same but the implementor
didn't do it right.

Last point. What about if data sources are similar but not the same. For
example, they contain a user name and password, but you are free to use the
DataSource.getConnection(String,String) method to override. Is it ever
reasonable for Mondrian to regard these as the same, and if so, is there a
way we can implement it?

Julian 

> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of Pedro Alves
> Sent: Tuesday, October 06, 2009 10:21 AM
> To: Mondrian developer mailing list
> Subject: [Mondrian] Mondrian's cache key is tied to the 
> actual datasource.Is this right?
> 
> 
> 
> While debugging http://jira.pentaho.com/browse/PRD-2067 , 
> that totally 
> stopped us from writing mdx reports in the new report designer, we 
> traced the issue down to the way mondrian caches the connections.
> 
> 
>  From RolapSchema.java:
> 
>          /**
>           * Creates a key with which to identify a schema in 
> the cache.
>           */
>          private static String makeKey(
>              final String catalogUrl,
>              final DataSource dataSource)
>          {
>              final StringBuilder buf = new StringBuilder(100);
> 
>              appendIfNotNull(buf, catalogUrl);
>              buf.append('.');
>              buf.append("external#");
>              buf.append(System.identityHashCode(dataSource));
> 
>              return buf.toString();
>          }
> 
> 
> Unless we pass the same dataSource object, we'll always get a 
> different 
> key; Thomas solved this issue by caching the datasource object on the 
> jfreereport-ext-mondrian code, ensuring the identityHashCode 
> is the same
> 
> 
> 
> But....
> 
> 
> Is this the best approach? For me, this seems the reason that, for 
> instance, olap4j is unable to share cache with pentaho inside 
> mondrian. 
> If this was something that was cached based on the connection string 
> instead of the dataSource object maybe we can get close to 
> what we all 
> want - a olap4j connector in mondrian
> 
> 
> -pedro
> 
> 
> 
> 
> 
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>