[Mondrian] connection pooling/cache linked to connection?

[Paul Stoellberger]

After you left I did some more research.
Schema.key + Schema.checksum are the same, but the MondrianCatalogHelper is causing a schema flush on the first call of Jpivot.
While we keep the connection (and schema), jpivot is dumping them and re-creating them.

If jpivot is opened before saiku for the first time, its sharing the same schema object.

This is quite erratic behaviour, but I hope a refactored connection management in the biserver this can be resolved adequately.

However, I am quite concerned about how mondrian and xmla olap4j connections drift apart in my codebase. This should really not be the case. 

-Paul


On Jul 31, 2012, at 12:04 AM, Julian Hyde wrote:

> Paul,
> 
> As I said on IRC this morning, for connections to share a cache they need to be using the same RolapSchema object. I don't know the details of how you are connecting (you mentioned that DynamicSchemaProcessor is involved), or remember the details of Mondrian's algorithm. But if the net effect is that different connections are getting different RolapSchema objects (and it sounds like this is the case), then you are sunk.
> 
> Julian
> 
> On Jul 20, 2012, at 8:30 AM, Paul Stoellberger <p.stoellberger at gmail.com> wrote:
> 
>> Hi,
>> 
>> Since I'm just investigating some caching issues I had to change our way of handling connections.
>> We used to have one connection per user / session that would be reused all the time for query executions, metadata requests, etc.
>> 
>> Now it seemed like if we keep it that way that the cache with other classes that create an olap4j/mondrian connection won't be shared unless I switch to "constant" connection creation (every time a connection is requested a new one will be created).
>> 
>> Is the assumption correct that cache sharing cant happen unless this is done?
>> (It seems to work with creating new connections all the time)
>> 
>> If so, I looked at the MondrianServer connectionMap and I can see a whole bunch of connections in there (we don't close them at the moment, as we reuse them all the time)
>> and I'm a bit worried that they don't get cleaned up... there are easily dozens of connections in there after a while.
>> 
>> How would you recommend handling this?
>> When we introduce some sort of connection pooling I'm afraid the cache sharing won't work or shall i create new connections all the time and just make sure I close them again once they've been used?
>> 
>> All of the above is very mondrian specfic. Since there is no real caching layer for XmlaOlap4jConnections that would have an extreme negative Impact on them.
>> I know that there are some existing caching providers for xmla, but they're more or less useless if the connection is using roles or e.g. CustomData.
>> 
>> I would try to avoid handling all connection types differently if possible, so having a common API to e.g. clear the cache would be quite good.
>> Would you say thats something we can introduce in the future or do you disagree in having those common calls at all?
>> 
>> 
>> -Paul
>> 
>> _______________________________________________
>> 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