Authorization Rules not thread safe

Authorization Rules not thread safe

Old forum URL: forums.lhotka.net/forums/t/8948.aspx


cejones posted on Monday, May 17, 2010

We recently encountered an issue with a web service that hung and took up the entire CPU.  A memory dump showed that it was calling Dictionary.TryGetValue as a result of Csla.ReadOnlyBase.CanReadProperty.   Since CanReadProperty writes to a dictionary without synchronizing first, that can lead to an infinite loop.  See more details as Tess explained it in her blog here.  Basically any multi-threaded application, web application or even WPF application with asynchronous binding, can run into this problem.

We are currently using CSLA 3.6.2, but it seems the problem will still exist in 3.8.3 and even 4.0.

We're just going to patch the version that we're running but I'm curious if there are other suggestions on using authorization rules with a multi-threaded application.

rsbaker0 replied on Monday, May 17, 2010

I just posted a related question on very much this same topic. CSLA has a few places in it that read dictionary objects without locking them while a write might be concurrently altering them...

 http://forums.lhotka.net/forums/t/8947.aspx

RockfordLhotka replied on Monday, May 17, 2010

You can't actually share an object instance across threads, and I suspect that's what you are doing?

CSLA objects are not threadsafe. Putting a CSLA object into a global cache on a server is off limits. If you must do such a thing, you'll need to clone the object into and out of your cache - thus ensuring that each thread has a copy of the object, not a shared instance.

On the other hand, if I'm making a faulty assumption and you are seeing this issue without a shared object instance, please let me know, because that would be a problem I'd want to explore further.

rsbaker0 replied on Monday, May 17, 2010

Not even "read only" objects like NameValueListBase, etc??? It never even occurred to me to worry about thread safety for an object that is never changed after it has been created.

RockfordLhotka replied on Monday, May 17, 2010

NVL is probably fine.

ReadOnlyBase is the problem, because it has authz rules. Those rule results are cached. When the object detects that the principal has changed, it discards the cache.

If the object is used by two threads/users at the same time this can obviously cause nasty issues.

Now I suppose if your ROB object has not authz rules this is a non-issue. And you could ensure it is a non-issue by overriding CanReadProperty() and just return true - thus avoiding the invocation of the authorization system completely.

But as a general rule, ROB objects shouldn't be shared across threads.

Copyright (c) Marimer LLC