PRB: Thread Safety for DAO/Jet 3.5ID: Q169395
|
Thread Safety with Jet has been achieved with the release of DAO 3.5, but only for applications built with the _UNICODE switch. 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.
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 can 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.
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.
This behavior is by design.
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 : kbcode kbDAO kbDatabase kbMFC kbVC kbVC500 kbVC600
Version : 5.0 6.0
Platform : NT WINDOWS
Issue type : kbprb Last Reviewed: July 9, 1999