Re: Multi Thread App

On Tue, 6 Jan 1998, Alexander Jaremenko wrote: } Hello Mr Kagel, } Thank You for response. } } > ODS/ESQL-C versions 7.21 and later support threaded applications. } > Versions prior to 7.13 supported only one connection per process and } > 7.13->7.20 supported multiple sessions but only the main thread could } > access these. Version 7.21 is fully thread safe. A thread can enable } > any suspended connection and so multiple threads can share multiple } > connections in a meaningful cooperative way. } } That's fine. I have ESQLC v. 7.22 for Solaris x86 and printed programmer's } manual for v.7.1 :-). Because of that maybe I have some misunderstanding } for threaded ESQLC applications . Exuse me my wrong English, but I wanted } to know: } do I need distinct cursor and statements ids in different connections ? } Maybe multiple threads is not a right question here. As I understand it } each connection application makes is represented as different session } within ODS. And different user's sessions have separate name space. I } didn't try it for this moment yet ... You use the CONNECT TO ... AS <connection name> statement repeatedly with different connection names (which can be managed in host variables) to open multiple connections. Once a connection is open it is either active or dormant. To make a connection active use the SET CONNECTION <connection name> command for any dormant connection. To make a connection dormant use the SET CONNECTION <connection name> DORMANT in the thread for which that connection is currently active. Once a connection is dormant any thread within the application can activate it and take it over. In this way you could have either a set of connections dedicated to particular threads or have a pool of connections which a pool of threads can access as needed. (For example to build a threaded web server that maintains a set of connections identified using a magic cookie returned to the client, any available thread could pick up the request and find the connection associated with the cookie value and activate it to continue processing a request.) Hope that this helps. Art S. Kagel, kagel@bloomberg.com