Re: Trying to build a library that uses some ESQL generated code

"Art S. Kagel" wrote: > > You cannot share a single ESQL connection between multiple threads > simultaneously. You have to suspend the connection (SET CONNECTION ... > DORMANT) in thread A then thread B can enable it (SET CONNECTION ...) for > its own use. Also make sure that you use the thread-safe versions of the > ESQL libraries (esql -thread or esql -libs -thread)! Of course you can > open a separate connection for each thread and keep it permanently which > will reduce the inter-thread coordination overhead and eliminate a mutex > or three. Well this worked up to the point where I removed the mutexes; "it" doesn't seem to like me trying to use two connections on two different threads simultaneously. Each thread creates a uniquely named connection; lets it go dormant and either reusese or creates the named connection again when its executed again. I'm using the _lwp_self() api to get a thread id that is used in naming the connection. If I let two threads enter the database access section of the code at the same time one of them fails to call "set connection ..." on a connection that is only ever available to itsself. I'm doing a big "see how long the import will take" test at the moment so I can't tell what the SQL error code I get is. Should I expect this to "work" assuming that I have compiled the esql program with the right flags? -- Ben Gould

Ben Gould wrote: > > "Art S. Kagel" wrote: > > > > You cannot share a single ESQL connection between multiple threads > > simultaneously. You have to suspend the connection (SET CONNECTION > > ... DORMANT) in thread A then thread B can enable it (SET CONNECTION > > ...) for its own use. Also make sure that you use the thread-safe > > versions of the ESQL libraries (esql -thread or esql -libs -thread)! > > Of course you can open a separate connection for each thread and > > keep it permanently which will reduce the inter-thread coordination > > overhead and eliminate a mutex or three. > > Well this worked up to the point where I removed the mutexes; "it" > doesn't seem to like me trying to use two connections on two different > threads simultaneously. > > Each thread creates a uniquely named connection; lets it go dormant > and either reusese or creates the named connection again when its > executed again. I'm using the _lwp_self() api to get a thread id > that is used in naming the connection. > > If I let two threads enter the database access section of the code at > the same time one of them fails to call "set connection ..." on a > connection that is only ever available to itsself. I'm doing a big > "see how long the import will take" test at the moment so I can't > tell what the SQL error code I get is. I fail to see why there is a problem identifying the error; without the error, we cannot begin to guess whether you've made a mistake or the system is misbehaving. > Should I expect this to "work" assuming that I have compiled the esql > program with the right flags? Given the precautions you speak about, and the use of WITH CONCURRENT TRANSACTION on all connections, what you describe should work. But there are enough possible ways to hang yourself with a multi-threaded program that I'd not be confident that all possibilities were accounted for yet. There is also the chance that there's a bug somewhere. I haven't tried it, so I can't give more definitive answers. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>

Jonathan Leffler wrote: > I fail to see why there is a problem identifying the error; without > the error, we cannot begin to guess whether you've made a mistake or > the system is misbehaving. The only problem I have is time... > > Should I expect this to "work" assuming that I have compiled the esql > > program with the right flags? > > Given the precautions you speak about, and the use of WITH CONCURRENT > TRANSACTION on all connections, what you describe should work. But > there are enough possible ways to hang yourself with a multi-threaded > program that I'd not be confident that all possibilities were accounted > for yet. There is also the chance that there's a bug somewhere. I > haven't tried it, so I can't give more definitive answers. Having finally found the part of the esql manual that I should have found a few days ago - specifically regarding threaded applications - I think that I will need to build my own threads library because I believe that the server that I'm writing this plugin for implements its own thread handling. I just wanted to hear that this "should" work so that I could go on with investigating why it didn't... Thanks for all your help to date with getting me up and running with this new environment. -- Ben Gould

After some further investigation; chancing upon the statement do { $ set connection foo; } while (SQLCODE == -1802) enabled me to resolve the concurrency issues *sigh* wish I'd spotted this earlier. -- Ben Gould