Using multicast socketing to deal with ADO.NET concurrency

[Jay Riggs]

A little knowledge can be a dangerous thing.

I've been reading up on networking programming in the .NET Framework
and came across a chapter on multicast sockets. The chapter includes
a sample chat program that's easy to implement and I thought that
using this technique would be a perfect way to handle concurrency
issues for a test database I'm developing where there's likely to be
concurrency issues.

A number of strategies come to mind. One is that when a user attempts
to edit a record his UI can send out a query to all other users asking
if they have the record locked. If so, the user is prevented from
editing the record and is warned. All this of course happens behind
the scenes; user's wouldn't see any of it.

One obvious disadvantage is the load placed on a network. From what I
read though, multicast sockets are relatively easy on networks (and I
don't foresee having to transmit more than a few characters a pop),
and in my case my company is small (about 20 users).

I haven't seen using this technique for handling ADO.NET concurrency
discussed anywhere, and I'd like to get opinions on how feasible this
is (without going into gory details on my company's network
architecture.

Thanks
-Jay

Feel free to contact me privately:
jriggs atsymbolhere community dotcharacterhere net

 

[Ian Posner]

The "pessimistic" style of locking you refer to (as implemented in Access)
is really unsuitable for anything more than a few users. Why? Because users
have the habit of locking a record then going to lunch, or worse on holiday!

SQL Server is designed for optimistic locking, so use it that way, i.e when
updating,update the row based upon its primary key plus a timestamp column
value previously read. If no records are affected, then someone else has
modified/deleted the row in the meantime and the error should be displayed
to the user elegantly, e.g.

update mytable
set column1 = <anything>
from mytable
where primarykeycolumn = 56
and timestamp = '0x04efes2'

if @@rowcount <> 1
raiserror ('The row you are attempting to save has been modified/deleted by
another user', 11 , 1)

--

Ian Posner


A little knowledge can be a dangerous thing.

I've been reading up on networking programming in the .NET Framework
and came across a chapter on multicast sockets. The chapter includes
a sample chat program that's easy to implement and I thought that
using this technique would be a perfect way to handle concurrency
issues for a test database I'm developing where there's likely to be
concurrency issues.

A number of strategies come to mind. One is that when a user attempts
to edit a record his UI can send out a query to all other users asking
if they have the record locked. If so, the user is prevented from
editing the record and is warned. All this of course happens behind
the scenes; user's wouldn't see any of it.

One obvious disadvantage is the load placed on a network. From what I
read though, multicast sockets are relatively easy on networks (and I
don't foresee having to transmit more than a few characters a pop),
and in my case my company is small (about 20 users).

I haven't seen using this technique for handling ADO.NET concurrency
discussed anywhere, and I'd like to get opinions on how feasible this
is (without going into gory details on my company's network
architecture.

Thanks
-Jay

Feel free to contact me privately:
jriggs atsymbolhere community dotcharacterhere net