Multi Threaded Application

Multi Threaded Application

Post by Michael P. Wheele » Sat, 02 Feb 2002 01:14:18



I'm currently looking at converting several application into 1 multithreaded
application, but I have one concern that I think can be easily addressed.
How does each thread guarantee that after an SQL call that the sqlca. data
that it is looking was for that threads call and not someother SQL call from
a different thread.
 
 
 

Multi Threaded Application

Post by Jonathan Leffle » Sat, 02 Feb 2002 16:34:02



> I'm currently looking at converting several application into 1 multithreaded
> application, but I have one concern that I think can be easily addressed.
> How does each thread guarantee that after an SQL call that the sqlca. data
> that it is looking was for that threads call and not someother SQL call from
> a different thread.

It's a valid concern.

The threaded ESQL/C library performs that service for you.

Take a look at the sqlca.h header, and you find that sqlca is defined as a macro
that calls a function that returns a pointer to the relevant per-thread sqlca
structure and dereferences it - something like:

#define sqlca (*ifx_thr_sqlca())

--

Guardian of DBD::Informix 1.00.PC1 -- see http://www.cpan.org/
#include <disclaimer.h>

 
 
 

1. Multi-threaded Application

Don't know exactly where to post this question, but I'll give it a try here:

We are writing a VC++ multi-threaded application connected to a SQL
Server/MSDE database through OLE DB (ADO). All threads use one and the same
connection. There are many 'critical' threads involved (such as reading
alarms from a file and storing these in the appropriate tables). Now, the
problem is that if one thread is busy writing stuff in the database and
another thread wants to do the same or another thread simply wants to read
some data from the database, we very often get the following error:

'Connection is busy with another HSTM'

You must understand that this application is very 'critical', i.e. we cannot
afford to loose any data, in other words we can't afford the above error. We
are considering the following modifications to our design:

- Increase the number of simultaneous connections, i.e. maybe a connection
per thread, thus decreasing performance on the client side (yes, there are
several client applications connecting to the same database also)
- Keeping only one thread but implementing some 'retries' with a specific
time-out catch, thus decreasing performance on the server side application

What's best? Is there another way to cope with the problem? Any suggestions,
remarks, thoughts, ...?

Thanks a lot,

SLE

2. onstat -p all zero

3. DAO in a multi-thread application.

4. US-CA-Sr Programmer/Analyst Needed (Recruiter)

5. CDatabase objects in a multi-threaded application

6. Ddatabase, query, and schema sessions (XML DevCon 2001, New York, April 8-11)

7. Multi-threaded application doing MFC CDatabase->OpenEx()

8. Security in middle-tier

9. using dblib in multi-threaded applications on AIX

10. DB access from multi-threaded application

11. Multi-threaded application for Informix On-line

12. Multi-threaded applications for On-Line

13. Multi-Threaded Application accessing diff Databases under diff instances