DevForce Community Forum : Multi-Threading In a DevForce Application

Let�s begin our discussion of multi-threading with a definition of thread-safety:

For a class to be thread-safe, it first must behave correctly in a single-threaded environment. If a class is correctly implemented, which is another way of saying that it conforms to its specification, no sequence of operations (reads or writes of public fields and calls to public methods) on objects of that class should be able to put the object into an invalid state, observe the object to be in an invalid state, or violate any of the class's invariants, preconditions, or postconditions.

Furthermore, for a class to be thread-safe, it must continue to behave correctly, in the sense described above, when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, without any additional synchronization on the part of the calling code. The effect is that operations on a thread-safe object will appear to all threads to occur in a fixed, globally consistent order.

The relationship between correctness and thread safety is very similar to the relationship between consistency and isolation used when describing ACID (atomicity, consistency, isolation, and durability) transactions: from the perspective of a given thread, it appears that operations on the object performed by different threads execute sequentially (albeit in a nondeterministic order) rather than in parallel. [1]

The .NET Framework Class Library documentation for the DataSet class says this about its thread-safety:

This type is safe for multithreaded read operations. You must synchronize any write operations.

The same is true for the DevForce PersistenceManager. To make it thread-safe for write operations would require that we make thread-safe every method therein � and every method of the business objects it manages, including property setters. This would increase the PersistenceManager�s complexity � and degrade its performance � significantly. Every user of the PersistenceManager, and every use thereof, would incur the performance penalty, whether such users and uses required thread-safety or not.

[1] Excerpted from �Characterizing Thread Safety� by Brian Goetz, available on the web at:

http://www-128.ibm.com/developerworks/java/library/j-jtp09263.html

asynchronous queries can be launched simultaneously. You can read about asynchronous queries in the DevForce Developers Guide (in the chapter on Object Persistence), and see sample code in the Asynchronous Queries instructional unit that is shipped with the product.

Does this mean that you can�t do multi-threading (other than by using Asynchronous Queries) in a DevForce application? No, it does not. It just means that you should never share a single PersistenceManager, or any of the entities it manages in its cache, across multiple threads. Let us repeat:

o Never share a PersistenceManager across more than one thread.

o Never share entities from a given PersistenceManager in more than one thread.

Note that the problems that occur with multi-threaded applications are, by their very nature, timing-dependent and difficult to diagnose, reproduce, and test for. Your multi-threaded process can work successfully for long periods of time, then fail catastrophically when two or more inconsistent changes happen to be made simultaneously. You should definitely not count on this failure occurring at a convenient time!

If You�re Determined To Do Multi-Threading�

Be sure you really need multiple threads. Remember, if all you want to do is fetch data asynchronously, you will be fully satisfied with Asynchronous Queries. Don�t mess around with multi-threading if this is all you want to do.

Use caution when writing any multi-threaded app. Don't be lulled into a false sense of confidence just because it is easy to spawn a BackgroundWorker in .NET 2.0. Multi-threading is still hard. The BackgroundWorker made the syntax easy: it did not make good multi-threaded design easier!

If you�re new to multi-threaded programming, work with someone who has significant prior experience doing it, if at all possible. If you can�t arrange that, do some serious reading and study on the topic before attempting it on a critical application.

If your multi-threaded aspirations involve DevForce business objects:

Use a different PersistenceManager in each thread. Such PersistenceManagers can do anything a normal PersistenceManager can do; they can fetch (both synchronously and asynchronously), save, and so forth.
Never use PersistenceManager.DefaultManager when multi-threading � the DefaultManager is �global� to the AppDomain and will be shared among any threads in which it is used.
Never communicate entities across thread boundaries. If the caller must know about some entities, send a list of PrimaryKeys across the thread boundary in a call back. Alternatively, you could bury EntitySets in a call back to serialize copies of entities across the thread boundary.