| ENGLISH | JAPANESE |
The Servlet we have implemented for illustrating the use of prolog, MySQL, and Java, can only be safely used by a single user. Let us see first a problem occured by commenting out the line, 'abolish_facts();' in prologServ2.java. The modification hinders prolog to clear up the facts imported from RDB. When you submit your request, you get the same result as above, but if you re-submit the same request to the Servlet again, then you will be embarassed by the odd results (figure[An odd result])
This abnormality is due to the fact that the Servlet imports the set of facts into prolog again when it was evoked second time. The prolog process was running (or available) while Tomcat is alive, serveing you. Each time you send a requet to the Servlet, it imports the facts of child_of relation from RDB to prolog. You must, therefore, clear up the set of facts each time you call the Servlet.
The implication of this malfunction is that allowing another user to call prolog may lead to similar abnormalities. If the second user lets his Servlet to assert a set of facts of child_of relation and he does not clear them up immediately, The same set of facts are called by the Servlet developped by the first user. The point here is that prolog runs only in one process while Tomcat responds to the requests from several users. Sharing the same prolog process among different users may lead to inconsistency to some user.
The best solution would be to spawn out a new process for running prolog each time a user calles the Servlet. The solution is, however, unavailable to us because a servlet can only run multi-threads, on a single process. We have to, therefore, carefully control multi-threads on prolog so that they do not interfere each other by inserting or removing facts.
We can control threads in two levels, one within SWI-prolog and the other within JPL. SWI-prolog enables us to spawn out multi-threads and put control over them. The function is, however, in still pre-alpha state and can only be tested on Unix platforms. Moreover, JPL did not work well with the multi-thread-enabled SWI-prolog when I tested it on Linux.
The only possible way to control multi-threads in prolog is, therefore, to control them in JPL. The methods such as query(), oneSolution(), and allSolutions(), are in fact thread-safe. There is also a method lock(). (See "Multi-threaded Queries" in "High-Level Interface" for more detail.) We conclude that we should do our best by controling multi-threads at the level of JPL. (Needless to say, the inconsistency is unlikely to occur if executing prolog program does not involve updating facts.)
It is known that establishing connection with RDB using JDBC takes time. We had better prepare for some connections in the beginning and reuse them for letting users to get access to RDB. Some author claims that sharing connections reduces sometimes the accessing time to one tenth. I believe that we should defenitely employ such a mechanism for real web applications, but we do not need to be so sensitive to the loss as long as only the single developer runs the Servlet on Windows9X.
In analogy with the case of RDB connections, one may want to manage the loading SWI-prolog. That is, one may want to terminate the prolog process when no thread uses it. We cannot, however, terminate a prolog process as the attempt leads to shutting down Tomcat. We can therefore only hold the process to the end of a Tomcat session once it was evoked by some servlet.