Re: database engine

>Date: Fri, 8 May 92 14:03:24 PDT >From: uunet!saad-emh1.ARMY.MIL!Doimic01 >To: informix-list@RMY.EMORY.EDU >Subject: Re: database engine >X-Informix-List-Id: <list.1154> I've kept quite a lot of the preceding mail because I think it makes my answer clearer. The discussion is about why the database engine is a separate process from the application program. >->>How is information passed back and forth between the 4gl/esql-C >->>program and the database engine? For example, if a query returns 100 >->>rows from a table, how can a pointer to this information be passed back >->>to the calling program? >->I believe that the two programs are link by a pipe. Network version >->are probably linked by sockets. The selected data is returned across >->the pipe one row at a time. >Wow, that must be some kind of interface: requires 2-way pipe with >hand-shaking ("give me the next row now" and "okay, here's the next row"), >or ("forget the next row, give me a new list sorted some other way"). One or two minor details: on Unix, it uses 2 uni-directional pipes, one for the FE to talk to the engine, and one for the engine to talk to the FE. Networking products use a bi-directional socket over the network, but the FE on the local machine still talks to some local engine (or engine look-alike if you have 5.00 and are using a relay module) using the two uni-directional pipes. There is indeed a synchronous protocol with handshaking connecting the FE to the engine. It works roughly along the lines you said. >->>Why can't all functions that the engine fulfills be incorporated into >->>the 4gl/esql-C program itself? Why must we have this phantom program >->>floating around in the background? >->I have heard this strategy called dynamic or runtime linking. All of >->this backend code (about 300K on my system) could be linked into every >->program that you build, but it seem like a was of disk space. Also, you >->would be forced to re-link every program after every upgrade. >Yes, but how much of the 300K is really the database engine and how much >is for maintenance of the link between the engine and the program? And >every program you write probably wouldn't require the entire engine. For >example, if part of the engine dealt with re-indexing, then a program that >only did queries would not need that part of the engine. And relinking >shouldn't be a problem, since most programs need periodic modifications and >updates that require re-compiling anyways. Just my $0.02. There are several answers to that. One of them is that there is no way that I want uncontrolled programs accessing my databases -- they're far too important to let programmers destroy them:-} By having the program that actually accesses the database separate from the user program, you can do a whole lot of things that would otherwise not be possible, such as: * Have the program run without any unusual permissions (no SUID or SGID), yet still have the database protected from ordinary access by standard Unix programs. * Relocate the database onto a new machine without the user being aware. (Using I-NET or I-STAR and a modified DBPATH). * Change from SE to OnLine without the user being aware. Secondly: you say "if part of the engine dealt with re-indexing, ..." Sometimes, the quickest way of processing a given query is to have the engine build an index simply to answer the question. This would then require the indexing code to be present, just in case that is true. By the time you had produced a sub-set, you would likely find that you had saved a negligible amount of space. Thirdly: you say "how much of the 300k is really database engine...". The answer is most of it, though not as definitively as I would like (ie, more of the code than I find comfortable is to do with the communications, though analysing what gets included in the FE gives a biassed answer since much of the code there would be included in the engine even if the communication system was simpler). >Why the interest in the engine, aside from curiosity? >To understand/answer questions such as: I have a feeling that I lost a '>' here, so that rather than being a rhetorical question, it was a Q&A supplied by two people. >1) If the 4gl/esql-C program dies and the sqlexec engine is left > running by itself in memory (this happens, for example, when > the LAN goes down, or the user doesn't properly log-out), will > killing the sqlexec cause corruption in the database? Will letting > it run cause corruption? Killing the engine will definitely cause corruption. And it's another reason for having the engine separate from the FE. If the FE dies, the engine can clean up afterwards, rolling back the changes it made (if there is a transaction log), and generally making sure things are shut down properly. Letting the engine run should not cause corruption. In the odd cases where a FE program dies and the engine seems to go on forever (typically chewing up masses of CPU time while it is doing so), you will have to kill the engine. But do it gently: try signals 15 (SIGTERM) and 1 (SIGHUP), and SIGUSR1 (which varies: 16 on System V and 30 on SunOS (BSD?)) first, and allow it time30 on SunOS (BSD?)) first, and allow it time30 on SunOS (BSD?)) first, and all ow it time (say 10 seconds) to respond in each case, and only if all those fail should you go for the kill 9 (SIGKILL). Also, note that if the engine code were incorporated into the program and the program had a bug in it which went trampling over memory reserved by the engine, the database, which is a shared resource, could be irreparably damaged quite by accident. Hardly a desirable state of affairs for a valuable corporate resource. >2) Is it possible to write a stand-alone Informix 4gl/esql-C application > that can be ported from one machine (same model, of course) to another, > without Informix on the second machine? I know the answer to this (NO!), > but dBase allows you to write stand-alone applications, why not Informix? If you want dBase, use dBase: Informix doesn't licence things that way. > Once a C/Pascal/Cobol/Basic program is compiled, you don't need a $20K > compiler or interpreter to run it. It would be nice to be able to do the > same with database programs. > >->David Stockel >Todd Glidden, CSC, Sacramento Army Depot Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>