<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Matt,<br>I'm in the forums, but have no say in what goes into the next release.&nbsp; I am only suggesting it because I think the work is not huge and it is a performance improvement that doesn't break the existing architecture.&nbsp; Talk to Julian about it.<br><br>As for distinct count, there are two types of rollups that get done.&nbsp; You can actually roll up some distinct counts if the attribute that is being grouped (distinct is just like grouping except you don't record any statistics per group) is part of the grouping.&nbsp; For example if you want to find the number of distinct values of SALESPERSON and you are grouping over the organisation hierarchy then you can probably just use SUM.&nbsp; This is already build into
 Mondrian.<br><br>As for how that plays out in certain databases which use CUBE, ROLLUP and GROUPING SET (I think that's the Oracle syntax), I have to admit that I'm ignorant.&nbsp; I know it exists but that's about it.&nbsp; I come from SAS where we use PROC SUMMARY for that sort of thing and it doesn't handle distinct counts.<br><br>As for transaction contexts you have a problem.&nbsp; Most of the time your datastore is not changing and you perform read-only operations.&nbsp; You can under these circumstances not re-use the same transaction context.&nbsp; In fact Mondrian at present doesn't use the same transaction for different GROUP BYs on the fact table in order to service the one MDX query.&nbsp; Transaction contexts only become important when you want a consistent view of the data and the underlying data store is dynamically changing.<br><br><span>The problem is that even though we could in most cases make do with a non-transactional data store, all RDBMSs are
 transactional systems.&nbsp; They all use the CLI mapping of transaction to thread.&nbsp; That means that you use just one thread to get a connection, issue a query, then another etc then close the connection.&nbsp; If you want to issue parallel SQL queries on the same DB you need multiple threads openning different Connections that almost certainly don't share a genuine transaction context.&nbsp; In Java EE (and J2EE before it) there is still no standard way to launch a separate thread.&nbsp; You only service requests in the thread provided by the container.&nbsp; There are non-official 'standards' to do this such as IBM/BEA's CommonJ and JBoss's Asynchronous Beans.&nbsp; I've actually thought about this more in the context of partitionning along members than aggregations.&nbsp; Look at this thread to see how I have been thinking about this: <a target="_blank"
 href="http://www.theserverside.com/news/thread.tss?thread_id=43916#225895">http://www.theserverside.com/news/thread.tss?thread_id=43916#225895</a></span><br><br>Good weekend, Michael</div></div><br>
                <hr size="1"> 
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 <a href="http://fr.rd.yahoo.com/evt=42054/*http://fr.answers.yahoo.com">Yahoo! Questions/Réponses</a>.</body></html>