[BACK]Return to lonsql CVS log [TXT] [DIR] Up to [LON-CAPA] / loncom

Diff for /loncom/lonsql between versions 1.55 and 1.56

version 1.55, 2003/02/03 13:43:38 version 1.56, 2003/07/25 17:07:06
Line 39  lonsql - LON TCP-MySQL-Server Daemon for Line 39  lonsql - LON TCP-MySQL-Server Daemon for
 This script should be run as user=www.    This script should be run as user=www.  
 Note that a lonsql.pid file contains the pid of the parent process.  Note that a lonsql.pid file contains the pid of the parent process.
   
 =head1 DESCRIPTION  =head1 OVERVIEW
   
 lonsql is   The SQL database in LON-CAPA is used for catalog searches against
   resource metadata only. The authoritative version of the resource
   metadata is 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.
   
   The current database is implemented assuming a non-adjustable
   architecture involving these data fields (specific to each version of
   a resource).
   
   =over 4
   
   =item * title
   
   =item * author
   
   =item * subject
   
   =item * notes
   
   =item * abstract
   
   =item * mime
   
   =item * language
   
   =item * creationdate
   
   =item * lastrevisiondate
   
   =item * owner
   
   =item * copyright 
   
   =back 
   
   =head2 Purpose within LON-CAPA
   
   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.)
   
   The solution is to index various data fields that are descriptive of
   the educational resources on a LON-CAPA server machine in a
   database. Descriptive data fields are referred to as "metadata". 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.
   
   The obvious solution, using lonc to send a query to a lond process,
   doesn't work so well in general as you can see in the following
   example:
   
       lonc= loncapa client process    A-lonc= a lonc process on Server A
       lond= loncapa daemon process
   
                    database command
       A-lonc  --------TCP/IP----------------> B-lond
   
   The problem emerges that A-lonc and B-lond are kept waiting for the
   MySQL server to "do its stuff", or in other words, perform the
   conceivably sophisticated, data-intensive, time-sucking database
   transaction.  By tying up a lonc and lond process, this significantly
   cripples the capabilities of LON-CAPA servers.
   
   The solution is to offload the work onto another process, and use
   lonc and lond just for requests and notifications of completed
   processing:
   
                   database command
   
     A-lonc  ---------TCP/IP-----------------> B-lond =====> B-lonsql
            <---------------------------------/                |
              "ok, I'll get back to you..."                    |
                                                               |
                                                               /
     A-lond  <-------------------------------  B-lonc   <======
              "Guess what? I have the result!"
   
   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.
   
   Thus, lonc and lond spend effectively no time waiting on results from
   the database.
   
 =head1 Internals  =head1 Internals
   
Removed from v.1.55  
changed lines
  Added in v.1.56

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