Re: Informix ESQL/C seems to block

>From: Ken Crismon <kcrismon@earthlink.net> >Date: Thu, 17 Oct 1996 18:56:49 +0000 >X-Informix-List-Id: <news.29434> > >A not so brief discussion of our product. > >We are developing a server application that runs on various UNIX platforms >and Windows NT. It services several concurrent client connections that >wish to passthrough to the Informix ONLine engine on another remote >machine. Essentially our server application manages multiple connections >to it and each connection will establish a connection to the Informix >engine. Each of our connections are managed within the application by our >own scheduling algorythm, if any of these connections call into a blocking >function such as the ESQL/C generated code to execute SQL requests the >whole application blocks until the ESQL/C call returns. This is bad news >when the application is trying to service 100+ conections all trying to >retrieve data from Informix. > >Essentially it appears as though ESQL/C is a blocking client API. I am not an expert on NT. On Unix, by default, ESQL/C is indeed a blocking client API. >I have explored setting up KAIO on our HP-UX machine where the Informix >Engine is running and to no avail the ESQL/C portion of the application >still blocks. I'm not clear how KAIO might be thought to affect the ESQL/C API. It affects how data is written to disk, not how it is passed to the client. >Informix Technical support really did not provide any reasonable answers >as to whether ESQL/C v7.2 is a blocking API. They said tweak the KAIO on >the server and also the priority in the ONCONFIG file. Each of these >still produced a blocking API. I think these suggestions are red herrings. >Now for the question....... > >Can anyone in the Informix User Community tell me whether the Informix >client API is blocking API or not? By default, it is. >If it is then I am going to have to jump through a lot of hoops to produce >a non-blocking application. Maybe, but they shouldn't be too big a set of hoops. On Solaris, at least, and in version 7.2 at the earliest, there is an option to link ESQL/C with the thread-safe libraries. This is supposed to allow a single ESQL/C process to have multiple threads, and each thread can use a separate connection to the database. Each thread uses a blocking API, but the application as a whole is not blocked unless all threads are waiting on the ESQL/C API. You have to explicitly link with the threaded libraries: esql -thread -o program obj*.o I'm not sure whether you need to compile the source with the -thread option too; it would do no harm to do so, and might be necessary. You could always do the necessary manual bashing -- or read the release notes, perhaps. I believe there are hooks to support a number of different threads packages, but that the initial release on Solaris only supports one threads package; I haven't looked to check which. >A quick side note, Sybase CT-Library and DB-Library both are non-blocking >on all platforms. The latest Oracle OCI client API is also reputed to be >a non-blocking API. And we provide it as an option. There is a performance penalty to be paid for a threaded architecture -- you have to check mutual exclusion of resources, etc. >Also the ODBC architecture provides for asynchronous statements and >connections. Essentially the ODBC model is very simple. Make an >SQLExecute() call and if it returns SQL_STILL_EXECUTING then call it again >until the function returns SQL_SUCCESS or SQL_ERROR. This allows the >programmer to yield to other components of the application so that they >may do the work they need to do such as field other client connections. I think this is OK in thread-safe ESQL/C. I have not done the formal manual bashing or testing to verify the statements I've made, but I believe they are basically accurate. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>