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

[Pedro Alves]

I've had the same problem in 2 or 3 different occasions (platform, cdf 
wizards - olap4j and mondrian apis - and now reporting), and in all of 
them I've had the same problem; If I can't account for how existent 
application work, I can say that in all this scenarios my expectation as 
a developer was the same:


Same connection (either jdbc or jndi) + same catalog == connection sharing.


While I can imagine lots of ways for me to force a datasource to be 
different (thus not reusing cache) it has proven to be impossible to 
consider it the same; I noticed while developing a report that mondrian 
was caching > 50 RolapSchemas (!!).


(I'll answer the specific questions tomorrow)


-pedro


On 09/10/06 21:19, Julian Hyde wrote:
> 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
>>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian