<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE type=text/css>DIV {
        MARGIN: 0px
}
</STYLE>

<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=890593607-13032007><FONT face=Arial 
color=#0000ff size=2>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi 
Michael,</SPAN><?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I don't see any 
problems for you to make changes to mondrian.&nbsp; But I have some 
concerns:</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think the changes you 
are about to make are quite huge and will have an impact of how mondrian will 
behave.&nbsp; Since this is the first source contribution you are about to make, 
I urge you not to check anything into perforce before it is actually working and 
passing all regression tests.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think most developers 
of mondrian have ongoing projects that are using mondrian, I think this 
is</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">becoming more and more 
an important issue.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">For me: it must be able 
to flush aggregates and member cache using the plug-in and cubes not</SPAN><FONT 
face="Times New Roman" color=#000000 size=3> </FONT><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">maintaining cache 
should be able to load their own data, without messing with global 
cache.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">And since a dynamic 
database cannot easily be simulated in a regression test, I think if you 
are</SPAN><FONT face="Times New Roman" color=#000000 size=3> </FONT><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">serious about tackling 
the read-consistency for near-real-time data, you need a realistic (dynamic) 
database to test against.&nbsp; And the database must be large enough to be able 
to see realistic performance.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>It is 
also advised to test with virtual cubes, cubes maintaining cache (with aggregate 
tables) in combination with cubes not maintaining cache (without aggregate 
tables), shared dimensions and so on…</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I released my project 4 
weeks ago, not even using the latest version of perforce, since at a given point 
mondrian-head was completely broken for me.&nbsp; While I know software always 
has some bugs that need to be patched, things that are not tested and are 
breaking mondrian should not be checked in.&nbsp; All too often I had to sync 
with perforce to solve a bug and this ended up in a nightmare, spending most of 
my time finding out&nbsp;what&nbsp;change was causing mondrian to 
break.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">When mondrian 2.3 will 
be released, it is most likely that there will be&nbsp;some 2.3.x version 
containing some patches.&nbsp; I think it must be possible to make those patches 
without having to drag new huge features along.</SPAN><o:p></o:p></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT size=3><FONT 
color=#000000><FONT 
face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Bart</SPAN><o:p></o:p></P></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=890593607-13032007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr align=left><FONT face=Tahoma size=2><B>From:</B> 
mondrian-bounces@pentaho.org [mailto:mondrian-bounces@pentaho.org] <B>On Behalf 
Of </B>michael bienstein<BR><B>Sent:</B> vrijdag 9 maart 2007 
11:36<BR><B>To:</B> Mondrian developer mailing list<BR><B>Subject:</B> 
[Mondrian] Multithreading etc<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV 
style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
<DIV>I sent this to the list but it gets bounced because I attached the code in 
a zip file.&nbsp; How do I send code through without checking it in because it 
is still orthogonal to the codebase?<BR><BR>Michael<BR>----<BR><BR>Well, I have 
code that works for multi-threading infrastructure so I would like to know if it 
is worth continuing with this or not.<BR><BR>As for ROLLUP/CUBE my thoughts 
are:<BR>1) Either we keep the codebase simple by sticking to a standard 
(SQL2003) even if this standard is not yet implemented widely and certain 
databases have better special features than others, or we allow a per-database 
SQL generation system.&nbsp; The argument for the second makes sense only if the 
developer resources to write and maintain each dialect comes from the database 
vendor or their community.&nbsp; Mondrian is probably at a stage that such 
discussions can be undertaken with the database vendors.<BR>2) Architecturally 
this implies loading multiple Aggregations from one SQL query.&nbsp; That 
requires a rethink of the way the cell cache loading is done because at the 
moment an Aggregation is loaded one at a time and in a synchronized block on the 
Aggregation.&nbsp; Similar concerns have to be dealt with for in-memory 
rollups.&nbsp; I think that synchronized is too forceful.&nbsp; We need 
something more like a Lock from java.util.concurrent so we can do 
tryLock().&nbsp; Look at the TxLock idea I have in the code I'm 
attaching.<BR><BR>As for multi-threading:<BR>I have only written most of the 
base infrastructure, not the cell loading.&nbsp; To integrate would require a 
significant amount of work in Mondrian's code to pass all interaction with 
Mondrian through TxSystem.runWithTx().&nbsp; <BR><BR>Basic concerns are:<BR>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>1)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>Threads should be able to share data related to the 
request across the threads.</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>2)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>A Thread should be loaned to a request and returned 
in a way that is well-nigh fail-safe (i.e. the thread shouldn’t keep running of 
the request fails in some way).</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>3)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>We should be able in a parameter of some sort decide 
to NOT use threads at all.</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>4)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>The number of threads should be 
configurable.</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>5)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>There should be an independence from the rest of the 
code base.</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>6)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>We should be able to make use of custom thread pools 
or use managed thread pools from the application server.</SPAN></DIV>
<DIV class=MsoNormal 
style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><SPAN><SPAN>7)<SPAN 
style="FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-size-adjust: none; font-stretch: normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></SPAN></SPAN><SPAN>Then there is a relatively minor issue with 
read-consistency for near-real-time data that turns out to be a real 
head-ache.<SPAN>&nbsp; </SPAN>This can be done by either: using the transaction 
semantics of the underlying data store <U>or</U> modifying all SQL requests and 
cache interactions with a timestamp and/or transaction id of some 
sort.<SPAN>&nbsp; </SPAN>E.g. when an MDX requests begins it asks the underlying 
data store for the id of the last completed transaction that modified data and 
keeps this in a request-scope available to all threads.<SPAN>&nbsp; </SPAN>Then 
it appends “changedTxId &lt;= ${lastTxIdWhenFirstEntered}” to each WHERE 
clause.<SPAN>&nbsp; </SPAN>If however we use the underlying data store’s 
transactions then we must keep open the JDBC Connection for the duration of the 
request reusing it on the same thread for each interaction with that data 
store.</SPAN></DIV>
<DIV class=MsoNormal><SPAN>Now, I think that the best way to take advantage of 
multiple threads in the storage system is NOT launching multiple SQLs on the 
same star schema but different aggregations but rather to use 
<U>partitioning</U> of data.<SPAN>&nbsp; </SPAN>That is to segment the cell data 
(and maybe dimension data) based on values of certain columns.<SPAN>&nbsp; 
</SPAN>For example year&lt;2007 and year=2007 in<SPAN>&nbsp; </SPAN>two 
different partitions.<SPAN>&nbsp; </SPAN>This can be introduced slowly by simply 
making a RolapStar one Partition for the moment.<SPAN>&nbsp; </SPAN>Having said 
that aggregation tables are also a type of Partition and hitting two of them at 
once should be quite easy.</SPAN></DIV>So the design I am introducing has the 
following features:<BR>1) A scope for "request" or "interaction" that is larger 
than the Thread that begins it.&nbsp; Since this is similar to a transaction 
I've called it a Tx.&nbsp; See the mondrian.tx package.&nbsp; Each sub-system in 
Mondrian can enlist a representation of itself in the Tx.<BR>2) Break up the 
different tasks performed into Task objects that can be run potentially in 
parallel.&nbsp; Allow a set of Tasks to be tied to the same Thread so that the 
same JDBC Connection can be used for all of them for read-consistency and 
cleaned up at the end of the Tx.&nbsp; This is done declaratively so the 
implementation can be changed easily.&nbsp; The implementation can also ensure 
that the J2EE context is passed onto separate threads (JNDI, context class 
loader etc).<BR>3) A system of fail-quick locks at the Tx scope rather than just 
Thread scope.&nbsp; <BR><BR>If this is worth persuing as a design for the next 
version then good.&nbsp; If not I'll stop now.<BR><BR>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>. 
<BR>______________________________________________________________________<BR>This 
email has been scanned by the Email Security 
System.<BR>______________________________________________________________________<BR></BODY></HTML>