Shared state

Jul 10, 2009 at 9:21 AM
Edited Jul 16, 2009 at 10:47 AM

I see that one of the upcomming "how to" articles will handle "How to protect shared state in an async service?" I would like to know some thoughts on this. From the outside perspective (client) making changes, a call to a XcoExclusive decorated function is sufficient. Occasionally, the service itself needs to get write access to its own state in a XcoConcurrent function. Is it advised to use normal locks in situations like these?

Jul 10, 2009 at 9:37 AM


The easiest way of protecting shared state within a single worker is to decorate the message handlers with [XcoExclusive] and [XcoConcurrent]. They are mapped to the CCR´s interleave receiver - with all its advantages and disadvantages.

If you choose not to follow a clear command-query-separation as these attributes suggest, then you´re on your own. Then use only [XcoConcurrent] to switch off any CCR state protection and do it like you want, e.g. by using a ReaderWriterLock in a more fine grained way.