[BACK]Return to SessionThre2.html CVS log [TXT] [DIR] Up to [LON-CAPA] / doc / gutshtml
File:  [LON-CAPA] / doc / gutshtml / SessionThre2.html
Revision 1.1: download - view: text, annotated - select for diffs
Fri Jun 28 20:30:29 2002 UTC (22 years, 5 months ago) by www
Branches: MAIN
CVS tags: version_0_99_3, version_0_99_2, version_0_99_1, version_0_99_0, version_0_6_2, version_0_6, version_0_5_1, version_0_5, version_0_4, stable_2002_july, conference_2003, STABLE, HEAD
HTML version of GUTS manual. Individual files will still need cleanup.

<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>