Hi,

Example:

Multi-user client/server environment. User #1 requests record X. Shortly afterwards, user #2 requests the same record. Both users now have the same data displayed. User #1 then makes changes to record X and commits them. User #2 is still seeing the old version of the record. Is it possible to somehow notify user #2's client application, so that it can update its display?

This is not so much to prevent lost updates (I could use other forms of concurrency control for this [as I've learned about tonight]), but more as a means of keeping the display of data accurate (up-to-date), so that users acting on such data would not be misled.

Are there any frameworks which handle similar situations?

Any ideas, thoughts, suggestions, . . . ?

Thanks,

_da.

This should be handled by record locking, which varies from one server technology to the next.

Hi blindman,

Like I said, it's not a question of handling problems with concurrency, but rather in keeping the display of data consistent with the database.

The only thing I can think of is to manually refresh (re-request) the record after a certain period of time has elapsed, but it would be nice if I could be pushed updates, rather than having to pull them.

Thanks,

_da.

IMHO, have a triggered procedure on the table send a request to a background task running on the same machine as the DBMS. The background task then spools the notifications out to the clients. This would be the best way to handle things if you were doing one of those fancy AJAX web interfaces.

Hi sco08y,

That's what I was thinking.

Someone else suggested having the clients message one another after they've successfully updated a record. That could also work, I guess.

Thanks,

_da.

Yes, but having the server broadcast a message when the tablle is updated provides central control of the messaging transmission process, and you don't have N copies of the message send floating around. IMO, it's just cleaner to keep the clients as simple as possible.

Hi loquin,

I also like the idea of central control, as well as a simpler client. However, I don't quite understand how the number of messages would be decreased?

Thanks,

_da.

I'm doubtful of that for two main reasons: a. you have to send additional traffic to determine whether the clients are able to see each other on the network b. the client now has to know more about the schema.

I wasn't talking about the messages, I was referring to the message send code. There would only be one instance of the broadcast code, not many.

If you use a message broadcast, (UDP) there wouldn't be any more messages - it's just that you have a more difficult time managing code that is widely deployed.

I see what you mean — I misunderstood.

Thanks,

_da.