On Dec 28, 1:19am, g.p.ciceri wrote:
> Subject: ST and dbms client libraries
> hi all,
> I'd like to know what kind of interaction can exist between
> state threads and a client dbms library (postgreSQL, in this case).
> Since I've read that ST must do socket IO
> [snip from docs]
> >The library's main limitation:
> > All I/O operations on sockets must use the State Thread library's
> I/O functions >because only those functions
> > perform thread scheduling and prevent the application's processes
> from blocking.
> I suppose that there will be problems using DBMS client libraries (since
> they DO socket IO); in particular a DBMS call can block the VP
> (and all the underlying STs), following the general examples/server.c
> server architecture.
> I'd like to know if there's some strategy to work around this
> kind of problems (apart the straightforward but lenghty way to
> re-implement the wire DBMS client/server comm. protocol using
> STs instead the native solution).
> One can observes that perhaps STs are not the correct way to interact
> with a DBMS, but the idea is to build a sort of DB proxy / TP monitor
> so the EDSM architecture seems to be a good applicative model: any
> remarks will be highly appreciated, as usual.
> Thanks for your time and Best Regards.
You are right -- if DBMS client libraries do socket I/O, they need to
be re-written to use ST I/O functions (it may be relatively easy since
all you need is to replace read()/write()/send()/recv()/etc. with
corresponding ST functions).
This is a general problem -- external libraries should conform to the
core server architecture. E.g., if the core server uses POSIX threads,
all libraries must be thread-safe and if the core server is ST-based, all
libraries must use ST socket I/O.
There is a way, however, to extend the functionality of the core server
by using separate "helper" processes. The core server may use ST functions
to communicate over some form of IPC (pipes, socketpairs) with "helper"
processes which in turn use external DBMS libraries. That makes sense
only if not all transactions require DB communications. Zeus web server
uses this approach -- static requests (and some ISAPI plug-ins) are served
by the core server but plug-ins that may use external libraries incompatible
with Zeus' EDSM architecture are executed by "helper" processes outside the
Internet Systems Engineering
Silicon Graphics, Inc.