[Mondrian] Re:VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP

[michael bienstein]

Bart,

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.

Michael


	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070123/1dea54b8/attachment.html