View Full Version : RE: Re : Re :

Pappyn Bart
01-23-2007, 11:21 AM

The exact details of transactions and connections I have not looked at. You might be right it is OK to use
a transaction per query. When the moment is there I will take a look.

Do note that it is the responsibility of the plug-in to detect changes, not mondrian itself. The plug-in can share
the transaction of the query and see changes before the transaction started and flush the cache involved.

First I will finish my current changes to RolapStar. If everything is working fine, I might take a look at connections
and transactions.

But there is one big problem for the moment : most connections to the database occur with the default connection
of the star and not with the jdbc connection of the RolapConnection.

Another problem is the hierarchy cache. In my case, hierarchy data is changing all the time, especially because
I have real-time data that is in properties of a dimension. But because the reading of the hierarchies is not in sync
with a mdx query connection, there could be problems. For example, jpivot can ask for hierarchy data without an
actual mdx query being executed. Not sure how to solve this one. Maybe this cache need to live on its own and
use a transaction per sql query?



From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of michael bienstein
Sent: dinsdag 23 januari 2007 15:55
To: Mondrian developer mailing list
Subject: Re : Re : [Mondrian]Re:VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP


Transactions on an OLTP Database should be short lived. You say "
When changes are detected, than the transaction for - this thread only - should be stopped and a new
one should be taken". You can't detect changes in a transaction. That's the Atomic property of ACID transactions. You *have to* use a separate transaction to detect changes.

Now how you keep cached values from one transaction to simplify the requirements of a second transaction is a complex question. ORM tools like Hibernate do this. I assumed that at least in a first pass we wouldn't. I thought of the following:
1) MDX Query begins - obtain a transaction context for the query.
2) MDX Query wants to pull data from a RolapStar or AggStar or just a table.
2a) Is this table a hot-updated table or a relatively stable data store? Stable data stores can be chaced globally but hot-cached tables use only transaction-local cache.
2b) If hot updatable - do we have the data in the transaction local cache? If yes, we're done. Otherwise go to 3.
2c) If stable table, does the global cache have the information? If yes then we're done. Otherwise go to 3.
3) Obtain the open connection in the current DB transaction if there is one. If not, make one, associate it with the query context/transaction context for future requests.
4) Query the data we want and place it into the cache (global or transaction local depending on the nature of the source of the data).
5) Keep going using this system until all data is found.
6) At end of query, dispose the transaction context - this will simply throw the transaction-local cache in the bin.