feelgood

Say in a inventory system scenario where User 1 calls up this particular product data object that contains information including quantity in stock. If for some reason, user 1 goes away from his desk for awhile. User 2 comes along and calls up the same data on his computer and then updates it. User 1 will no longer have the most recent information.

What's the best way to ensure that User 1 does get the most recent data?

I'm not really programming this thing, I'm just thinking theortically.

__________________
Looking out the window, that's an act of war. Staring at my shoes, that's an act of war. Committing an act of war? Oh you better believe that's an act of war

RelaX

Concurrency problems... don't you just hate them.
Actually I believe this one is called a 'dirty read'. Just google for 'concurrency problems' or similar and you'll get a lot of information.
However, the most common solution is just to lock the object.

__________________
The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.
- Nathaniel Borenstein

zen_tom

That's a tricky question. There are plenty of ways of dealing with it. Most of them deal with locking the data at some part of the system.
So for example, you can lock the data in the database when the first user looks at it, or you can lock the data at the application thread level when the first user looks at it. However, this causes problems whenever user two wants to update something, but can't because user 1 is in the way. So much for locking.

The second option is to allow for so-called 'dirty reads' this is the situation that you describe. Now the 1st user gets a set of data that was up-to date when he got it, but may change. This is kind of how the TFP works (you can leave a screen showing the latest posts up, but in the background all sorts of things could be happening etc)

The only way to keep no 1 up to date is to keep refreshing his data - perhaps every few minutes etc - or maybe only if he decides to change something.

feelgood

Refreshing Data is one way to go but it would be a problem in a company that has a large user base that would continuing to refresh data and putting a lot of stress on the database server.

One thing I've thought of was putting some sort of timestamp on when the data was last updated. If User 1 has data that was updated at 9am and User 2 updates it at 10am, then the user tries to update the data that was last updated at 9, the system could compare the timestamp and determine that User 1 is using out of date information.

__________________
Looking out the window, that's an act of war. Staring at my shoes, that's an act of war. Committing an act of war? Oh you better believe that's an act of war

kofspades

Try looking at "optimistic locking" design patterns.

__________________
Even if you stop the clock, it gives the right time twice a day.
Once we get out of the eighties, the nineties are going to make the sixties look like the fifties.