Re: Informix ESQL/C seems to block

On Solaris (2.4 and above) the DCE library needs to be installed for multithreaded esql/c applications to work. All the 7.20 (and above) ports should contain the threaded libraries. I think on the HP and IBM platforms, the esql/c thread libraries rely on native calls rather than DCE calls. The compile time flag is indeed -thread as Jonathon pointed out. % esql -thread -o <prog> <prog.ec> And the LD_LIBRARY_PATH needs to contain the path to the shared libraries. % LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${INFORMIXDIR}/lib:${INFORMIXDIR}/lib/esql % export LD_LIBRARY_PATH -- Bobby Software Development Engineer. International Product Development, Servers and Connectivity. Informix Software Inc, Menlo Park. On 22 Oct 1996, Jonathan Leffler wrote: |>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> | |