Simple WCF Service Request
I have a WCF service that has two methods:
Note. The wcf service and sql server are deployed on the same machine. Sql server has one table called employee that maintains employee information.
- Read () This method fetches all employees from the SQL server.
- Write () This method writes (adds, updates, deletes) information about employees in the employee table in the sql server.
I have now developed a desktop application through which any client can query, add, update and delete employee information by consuming a web service.
Question:
How can I handle this scenario if a mulitple client needs to update employee information at the same time? Is the sql server itself doing this using database locks?
Please suggest me a better approach!
source to share
Generally, in a disconnected environment, optimistic concurrency with rowversion
/ timestamp
is the preferred approach. WCF supports distributed transactions, but it is a great way to introduce long-term locks into the system. Most ORM tools support rowversion
/ timestamp
out of the box.
Of course, on the server you can use transactions (connection-based or TransactionScope
) to create separate methods of the "ACID" repository, but I would try to avoid wire-based transactions as much as possible.
Re comments; sorry, I honestly haven't seen these comments; sometimes stackoverflow doesn't make it easy if you get a lot of comments at once. There are two different concepts here; waiting is a symptom of blocking, but if you have 100 clients updating the same record, it makes perfect sense to block during every transaction. To keep things simple: if I can't demonstrate a bottleneck (requiring additional work), I would start with a serializable transaction around update operations ( TransactionScope
uses this by default). So yes: for most scenarios, you get the appropriate lock (ACID, etc.).
Nevertheless; second issue is concurrency: if you get 100 updates for the same record, how do you know who to trust? Most systems will allow the first updates and discard the rest as they operate with outdated data assumptions. The timestamp / rowversion label is present here. By applying "timestamp / rowversion matching in the UPDATE command", you ensure that people can update data that has not changed since it was checked out. For this purpose, it is common to keep the rowversion alongside any interesting data that you update.
source to share
Another alternative is that you could instantiate the WCF service as a singleton (InstanceContext.Single), which means it only works once. You can then store the simple object in memory for the purpose of blocking updates and blocking the update method based on that object. When update calls come from other sessions, they will have to wait until the lock is released.
Regards, Steve
source to share