+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 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 +"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. I now +answer this question in the format of Problem and Solution +below. +
++
+PROBLEM SITUATION: + + 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. + 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. + + 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. + +THE SOLUTION: + + A separate daemon process was created that B-lond works with to + handle database requests. This daemon process is called "lonsql". + + So, + 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. +