lonsql - LON TCP-MySQL-Server Daemon for handling database requests.
This script should be run as user=www. Note that a lonsql.pid file contains the pid of the parent process.
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).
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.
Returns: None
Inputs: $query, $custom, $customshow
Returns: A string containing escaped results.
Returns: nothing
Writes $message to the logfile.
Inputs: $cmd,$server
Returns: The results of the message or 'con_lost' on error.
Inputs: $cmd,$server
Returns: The results of the message or 'con_lost' on error.
Inputs: string to escape
Returns: The input string with special characters escaped.
Inputs: string to unescape
Returns: The input string with special characters unescaped.
Inputs: $author
Returns: 0 - this is not the authors home server, 1 - this is.
Returns: The full path to the users directory.
Returns: unescaped string of values.
Returns: unescaped string of values.