DevForce Classic: Is PersistenceManager thread-safe?

Please read this advice from our documentation:

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. At least 90% of the use cases that people submit to us for multi-threading involve retrieving data while other operations proceed. For this we have provided Asynchronous Queries. You call the PersistenceManager‟s GetEntitiesAsync() method, and we take care of putting the data retrieval operation on a separate thread so that the rest of your application can continue processing. Any number of such 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!

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

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

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.

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. IdeaBlade DevForce Developers Guide Object Persistence IdeaBlade DevForce Q&A.doc Copyright � 2006, IdeaBlade, Inc, all rights reserved 56

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: