CSLA.NET & Concurrency

pauldaly1982 posted on Thursday, July 20, 2006

Does CSLA.NET provide a mechanism for handling concurency issues?

We're currently checking update timestamps on rows in the database.  I'm wondering if the framework could notify the users if another user has an object "checked out" for writing... so that I could only allow the second user read access.  Could the framework send that second user a notification (via an event???) when the object is available for writing (when the first user "checks in" the object).

Thanks in advance for your help,

Paul Daly

Brian Criswell replied on Thursday, July 20, 2006

CSLA does not handle something like this automatically.  You would need to build it yourself.

RockfordLhotka replied on Thursday, July 20, 2006

And the reason it isn't in the framework is that it is really, really hard, and it requires some sort of server component. I think it impractical to come up with an answer that would fit into any IT environment, and so I've avoided putting any sort of answer into the framework.

To make this really work, what you need is a distributed lock and notification manager. The last one of these that I saw was on OpenVMS about 12 years ago - VAX clusters rocked!

What I'm talking about is a server that manages the communication, setting up publish/subscribe links between all the clients in your system.

This almost certainly has to be done with TCP sockets, because servers can almost never reliably initiate contact with clients. The client always needs to initiate contact with the server. Yet for this purpose you'd need virtually instant communication so polling is unlikely to work - so you end up with TCP socket connections. Much like IM software in many ways.

I wrote one of these a couple years ago, using Remoting. And it was cute, but largely useless, because it assumed that the server could contact the client to deliver messages... It was mostly a proof-of-concept in a sense.

The other thing to consider is the user experience. Concurrency is a best-guess until it happens, so you can't give the user a guarantee - just an indication.

Finally (and this is related), consider scalabiltiy and performance impacts. All this messaging isn't free, and you need to make sure to do it in a manner that will have the least performance impact. Beyond that however, is the scalabilty impact of all this message traffic buzzing around, and what it does to both your application and the network at large.

Bowman74 replied on Monday, July 24, 2006

<quote>
To make this really work, what you need is a distributed lock and notification manager. The last one of these that I saw was on OpenVMS about 12 years ago - VAX clusters rocked! ;)
</quote>

You and your silly VAX... ;)

Thanks,

Kevin

Allann replied on Thursday, July 20, 2006

Something that may help...  Rocky's answer would be the ultimate but I think there is a compromise depending on how critical the data is.

I use something like this; Note:  Tables that need to be monitored must use a Guid (or identity column) as the only primary key.

Create a "lock" table that contains the following columns

TableName = The table where the record is that needs to be locked for edit
RecordKey = Guid of the record
SessionId = Session or Computer name of the locking host
LockedTime = Time when the record is locked
MaxAgeInSec = How long can the record be locked (this is important, because people may load the record and walk away, or even worse, there session may crash, leaving the record in the "Lock" table)

When record is read via EditableRoot (Store procedure writes the lock record with current time, and the max time this record can be locked.)

When another EditableRoot accesses the record the SP will check the "lock" table and mark the item as ReadOnly (a new property on these special EditableRoots) and starts a poll timer (mine is set to 1 min) which will check if the record still exists in "lock" table, or if the "lock" has expired.

When the intial EditableRoot is Cleared, Disposed or a new record loaded, it deletes the lock record.

You get a slight increase in the SQL traffic with this implementation but because concurrency conflicts are not REALLY common the polling is not started, and you don't need to create a complex messaging system.

One final thing, you also need a service on the database server that monitors the "lock" table to remove expired locks.

Hope this makes sense, and fits your requirements.

Allan