File:  [LON-CAPA] / doc / gutshtml / SessionThre2.html
Revision 1.2: download - view: text, annotated - select for diffs
Tue Jul 22 14:47:00 2003 UTC (19 years, 2 months ago) by bowersj2
Branches: MAIN
CVS tags: version_2_9_X, version_2_9_99_0, version_2_9_1, version_2_9_0, version_2_8_X, version_2_8_99_1, version_2_8_99_0, version_2_8_2, version_2_8_1, version_2_8_0, version_2_7_X, version_2_7_99_1, version_2_7_99_0, version_2_7_1, version_2_7_0, version_2_6_X, version_2_6_99_1, version_2_6_99_0, version_2_6_3, version_2_6_2, version_2_6_1, version_2_6_0, version_2_5_X, version_2_5_99_1, version_2_5_99_0, version_2_5_2, version_2_5_1, version_2_5_0, version_2_4_X, version_2_4_99_0, version_2_4_2, version_2_4_1, version_2_4_0, version_2_3_X, version_2_3_99_0, version_2_3_2, version_2_3_1, version_2_3_0, version_2_2_X, version_2_2_99_1, version_2_2_99_0, version_2_2_2, version_2_2_1, version_2_2_0, version_2_1_X, version_2_1_99_3, version_2_1_99_2, version_2_1_99_1, version_2_1_99_0, version_2_1_3, version_2_1_2, version_2_1_1, version_2_1_0, version_2_12_X, version_2_11_X, version_2_11_4_uiuc, version_2_11_4_msu, version_2_11_4, version_2_11_3_uiuc, version_2_11_3_msu, version_2_11_3, version_2_11_2_uiuc, version_2_11_2_msu, version_2_11_2_educog, version_2_11_2, version_2_11_1, version_2_11_0_RC3, version_2_11_0_RC2, version_2_11_0_RC1, version_2_11_0, version_2_10_X, version_2_10_1, version_2_10_0_RC2, version_2_10_0_RC1, version_2_10_0, version_2_0_X, version_2_0_99_1, version_2_0_2, version_2_0_1, version_2_0_0, version_1_99_3, version_1_99_2, version_1_99_1_tmcc, version_1_99_1, version_1_99_0_tmcc, version_1_99_0, version_1_3_X, version_1_3_3, version_1_3_2, version_1_3_1, version_1_3_0, version_1_2_X, version_1_2_99_1, version_1_2_99_0, version_1_2_1, version_1_2_0, version_1_1_X, version_1_1_99_5, version_1_1_99_4, version_1_1_99_3, version_1_1_99_2, version_1_1_99_1, version_1_1_99_0, version_1_1_3, version_1_1_2, version_1_1_1, version_1_1_0, version_1_0_99_3, version_1_0_99_2, version_1_0_99_1, version_1_0_99, version_1_0_3, version_1_0_2, version_1_0_1, version_1_0_0, version_0_99_5, version_0_99_4, loncapaMITrelate_1, language_hyphenation_merge, language_hyphenation, bz6209-base, bz6209, HEAD, GCI_3, GCI_2, GCI_1, BZ4492-merge, BZ4492-feature_horizontal_radioresponse, BZ4492-feature_Support_horizontal_radioresponse, BZ4492-Support_horizontal_radioresponse
Convert GUTs HTML to PROPER line endings.

<html>

<head>

<meta name=Title content="Session Three: lonsql (Gerd)">

<meta http-equiv=Content-Type content="text/html; charset=macintosh">

<title>Session Three: lonsql (Gerd)</title>

<style><!--

.Section1

	{page:Section1;}

.Section2

	{page:Section2;}

-->

</style>

</head>

<body bgcolor=#FFFFFF class="Normal" lang=EN-US>

<div class=Section1> 

  <h2>Session Three: lonsql (Gerd)</h2>

  <p>This section describes issues associated with LON-CAPA and a SQL database.</p>

  <p>The SQL database in LON-CAPA is used for catalog searches against resource 

    metadata only. The authoritative version of the resource metadata is – as 

    discussed – an XML-file on the normal file system (same file name as resource 

    plus “.meta”). The SQL-database is a cache of these files, and can be reconstructed 

    from the XML files at any time.</p>

  <p>The current database is implemented assuming a non-adjustable architecture 

    involving these data fields (specific to each version of a resource). </p>

  <p> 1.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    title </p>

  <p> 2.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    author </p>

  <p> 3.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    subject </p>

  <p> 4.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    notes </p>

  <p> 5.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    abstract </p>

  <p> 6.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    mime </p>

  <p> 7.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    language </p>

  <p> 8.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    creationdate </p>

  <p> 9.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span> 

    lastrevisiondate </p>

  <p> 10.<span style='font:7.0pt "Times New Roman"'>&nbsp; </span> owner </p>

  <p> 11.<span style='font:7.0pt "Times New Roman"'>&nbsp; </span> copyright </p>

  <h3><a name="_Toc421867145">Purpose within LON-CAPA</a></h3>

  <p>LON-CAPA is meant to distribute A LOT of educational content to A LOT of 

    people. It is ineffective to directly rely on contents within the ext2 filesystem 

    to be speedily scanned for on-the-fly searches of content descriptions. (Simply 

    put, it takes a cumbersome amount of time to open, read, analyze, and close 

    thousands of files.) </p>

  <p>The solution is to hash-index various data fields that are descriptive of 

    the educational resources on a LON-CAPA server machine. Descriptive data fields 

    are referred to as &quot;metadata&quot;. The question then arises as to how 

    this metadata is handled in terms of the rest of the LON-CAPA network without 

    burdening client and daemon processes. I now answer this question in the format 

    of Problem and Solution below. </p>

  <p><b>PROBLEM SITUATION:</b><span style='font-weight:normal'> If Server A wants 

    data from Server B, Server A uses a lonc process to send a database command 

    to a Server B lond process.</span></p>

  <p>&nbsp;&nbsp;&nbsp; lonc= loncapa client process&nbsp;&nbsp;&nbsp; A-lonc= 

    a lonc process on Server A</p>

  <p>&nbsp;&nbsp;&nbsp; lond= loncapa daemon process</p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    database command</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp; A-lonc&nbsp; --------TCP/IP----------------&gt; 

    B-lond</span></p>

  <p>The problem emerges that A-lonc and B-lond are kept waiting for the MySQL 

    server to &quot;do its stuff&quot;, or in other words, perform the conceivably 

    sophisticated, data-intensive, time-sucking database transaction.&nbsp; By 

    tying up a lonc and lond process, this significantly cripples the capabilities 

    of LON-CAPA servers. </p>

  <p>While commercial databases have a variety of features that ATTEMPT to deal 

    with this, freeware databases are still experimenting and exploring with different 

    schemes with varying degrees of performance stability.</p>

  <p><b>THE SOLUTION:</b><span style='font-weight:normal'> A separate daemon process 

    was created that B-lond works with to handle database requests.&nbsp; This 

    daemon process is called &quot;lonsql&quot;.</span></p>

  <p>&nbsp; So,</p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    database command</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp; A-lonc&nbsp; ---------TCP/IP-----------------&gt; 

    B-lond =====&gt; B-lonsql</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    &lt;---------------------------------/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    |</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    &quot;ok, I'll get back to you...&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    |</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    |</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp; A-lond&nbsp; &lt;-------------------------------&nbsp; 

    B-lonc&nbsp;&nbsp; &lt;======</span></p>

  <p><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

    &quot;Guess what? I have the result!&quot;</span></p>

  <p>Of course, depending on success or failure, the messages may vary, but the 

    principle remains the same where a separate pool of children processes (lonsql's) 

    handle the MySQL database manipulations.</p>

</div>

<br

clear=ALL style='page-break-before:always;'>

<div class=Section2> </div>

</body>

</html>


FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>