Hi
I would like to know if in a client server application, CSLA is thread safe or if there are parts where I must implement thread safe operations.
Thanks for your help
Richard
Richard,
Your BOs are not thread-safe by default. You can make your BOs thread-safe if that is in your requirements.
DataPortal (Communication) portion of CSLA is thread safe. It was designed using a request-reply pattern. The default host and proxy implementations are using blocking calls for every request-reply cycle. If you are using remoting, IIS handles the threading for you on the server side. The DataPortal client is thread safe.
Regards
Yang
Hi, thanks for the answer. DataPortal is threadsafe, does that mean that I just have to take care for concurent acces in the database, but all the data portal creat, insert, etc. are safe ?
I think Yang meant that the transport aspects of the dataportal are safe. There is no thread safety in the DataPortal_XYZ methods or in the framework methods like BusinessBase's Save().
As you probably know, database concurrency and thread safety are two completely different issues.
Right. I don't think it is right to imply that the data portal is threadsafe.
The data portal is thread neutral, but not necessarily threadsafe.
What I mean by this is that you may not be able to call the data portal from multiple threads concurrently. However, you can use the data portal on a background thread, then the UI thread, then a different background thread - one at a time - and that should work fine (though see my note below about ApplicationContext).
In terms of thread safety:
The current implementation of the client-side DataPortal maintains a cached reference to a single instance of the proxy object. So if the client tried to do two data portal calls on two different threads, they'd both go through that same proxy instance.
That may or may not work, depending on the proxy implementation, and I didn't specifically design them to be threadsafe.
In other words, they might or might not be threadsafe - I can't say without carefully going through the code - but my guess is they are NOT. Quickly glancing at the RemotingProxy, it uses an instance field to store the actual remoting object, and so is probably not threadsafe. But the WcfProxy creates the WCF object per-call and so probably is threadsafe. The LocalProxy looks like it could be threadsafe, even though it does cache a reference to the server-side DataPortal class.
The server-side parts of the data portal, if you configure them as I show in the book, are threadsafe, because each client request runs on its own thread, using its own instances of the objects. Even if you configure it as a singleton it should be threadsafe, because I avoided using any instance fields on the server to help ensure statelessness and thread safety.
In short, you could tweak the client-side DataPortal class to NOT cache the proxy object (local or remote) and that should make the data portal threadsafe throughout.
Remember that ApplicationContext is PER-THREAD unless you are running in ASP.NET! You must move things like a custom principal or other context data to any background thread before calling the data portal, or you'll probably run into inconsistent results.
Thanks a lot for the answer. As I am not familiar with multithread development, I’ll have to think about yours answers. Thanks again :)
Richard
Copyright (c) Marimer LLC