Resource lock waiting for user interaction in client-server solution

Question

I have a client-server process that after a long-running operation (2-5 minutes) server side, ask the user to confirm or change the operation results.

User can take an hour or more to check the work done by the service, make changes and send those back to service.

In a perfect world nobody would change underlining source data used by the service to build the operation results.. but this isn't a perfect world!

How can I lock in order to prevent damage on my source data? I don't want SQL table lock... I'm thinking about a software mechanism like an in-memory table with all my operation requests and some interlock condition in order to put in a wait state operation that can damage other operation data.

Any other hint about?

Edit

More info about the process is probably necessary..

I have a timestamped entity that represent a point in time of an electrical network topology. The entity contains a list of all elements not energized.

The server process when called must take all entities not already processed and for each element create a list of

public class ElementRecord{
public string ElementName {get;set;}
public DateTime OffTimeStamp {get;set;}
public DateTime OnTimeStamp {get;set;}
}

Based on some business rules the server process aggregate the elements and wait for user ack or changes.

The problem is that after entities are loaded, real network can change and the table will change; also in a single point of time more elements can be de-energized so server process must invalidate. If user UI is already changing data I have to alert soon that probably some data is invalid.

What you will do?

Answer 1

I has encountered the similar requirement in one past project. Our solution was: after the server finished all operation, we copied all data which needs user to confirm to some temp data tables with timestamp for every row. And then, send mail to user to ask confirming, after the confirming, merge the temp data tables to our real data tables. We could not lock any data table, because other users need to change the table online.

Answer 2

How about adding an extra column to your tables to show that the data has been verified.

Data that doesn't have the verfied field set is then ignored. In a legacy system this would mean creating new tables and migrating the data over, but after that all you need is to ensure that only results where the verified field is set are returned to your code.

edit

What I was suggesting was that processes reading data can only use data that has been verified. If your user process is using and changing verified data then it must set the data unverified on retrieval, but it cannot retrieve that data if it has already been marked as unverified.

For new data you just create a new row with default data and get the row index back before verifying the new data. Your code then has the index and so the user can take as long as they like to verify the data and if they don't then you have the index so that you can delete the data already created.