PRB: Thread Safety for DAO/Jet 3.5

• Microsoft Visual C++, 32-bit Editions, version 5.0

SYMPTOMS

Thread Safety with Jet has been achieved with the release of DAO 3.5, but only for applications built with the _UNICODE switch. In order to use DAO 3.5 in a multi-threaded environment you need to use a class library (or other access mechanism) that is also thread-safe. Visual C++ offers two class libraries that use DAO 3.5: MFC DAO and the DAO SDK. Only the DAO SDK is itself thread-safe and therefore can use DAO 3.5 in a multi-threaded environment.

CAUSE

The Jet engine was originally written as a stand-alone desktop application, and originally conceived before thread-safety was as important as it is today. Jet 3.5 itself is not thread-safe. However DAO 3.5 is able to implement thread-safety using Jet 3.5 within an apartment model, but only if your application is compiled with the _UNICODE switch and using the UNICODE version of the DAO SDK.

Even with the DAO SDK and a UNICODE build, you need to create and terminate your DAO objects within the same thread. You must do this because Jet itself uses Visual Basic for Applications, which is also not thread-safe. You will encounter unexpected behavior if you try to pass DAO objects between threads.

DAO 3.5 offers thread safety (under UNICODE builds) because it creates a separate instance of Jet for each thread.

RESOLUTION

If your application does not use _UNICODE (for example, it is built using ANSI), it will not be thread-safe and Jet will not behave correctly in a multi-threaded environment.

In order for your application to use Jet correctly, the application and any mechanism using Jet must be thread-safe. There are two class libraries provided by Visual C++ for accessing DAO/Jet 3.5, but only one is thread- safe for _UNICODE builds.

The DAO SDK library for Jet 3.5 is thread-safe, mainly because it has no internal state variables. The DAO SDK is just a very thin wrapper around the DAO/Jet Automation Server.

MFC DAO, while modified to use Jet 3.5 if present on your machine, has not been modified to be thread-safe. It has a number of internal "state" variables that are not synchronized. Further, calls to critical operations such as database open and close have not been wrapped in any kind of critical section or lock to prevent re-entrance from other threads before completed. MFC ODBC, when rendered thread-safe, had a number of such critical sections "locked" in order to ensure synchronization by multiple threads. MFC DAO has no such implementation.

STATUS

This behavior is by design.

REFERENCES

For more information about creating multi-threaded applications using DAO 3.5, read the section "DAO and the Apartment-threading Model" in DAO SDK 3.5 online documentation.

Keywords          : dbDao MfcDAO kbprg
Technology        : kbMfc
Version           : 5.0
Platform          : NT WINDOWS
Issue type        : kbprb