Re: (long) Sniffing redo logs to maintain cache consistency?

Hi!

> But this cascaded warning would only go to the original user.

No, everyone will get the warning, because before modifying any data you first have to read it in the cache (or your user interface). When reading - you read the timestamp with the data, so any user reading the data will get the original timestamp. And any user writing the data back will get the warning/error, if cached timestamp won't match the current one in database. It can easily be done with a trigger or package code.

Of course they don't get a "cascaded" warning, instead they get "the data you wanted to change, has already been changed by someone else" type of warning. I think the "other user" usually doesn't care, why or by whom this change has been done, simply knowing that another user has changed the data is enough.

It's kind of optimistic locking.

> Maybe I'm missing something, but this seems to have a very large
> impact on the users. Rather than getting stale data warnings once
> in a blue moon, wouldn't you get them all the time? Even worse, if you
> look at the data and don't try to change it, you never know it's stale?
> When people complete their tasks, my tasks get changed (in the
> database only) from "Waiting on dependency" to "Ready for you to start",
> but when I view my task list from the cached data, I still see them as
> Waiting. And I will continue to see Waiting until someone updates my tasks
> (through java) and gets a stale data warning, or some kind of checkpoint
is
> done.

Would you prefer a solution, when one transaction blocks another one? If we are talking about 10000 users, you probably will start get a lot of locking/deadlocking issues then. Good luck. Or should I say Good lock ;)

I've worked with max. 1000 user systems (telco billing&customer care), the optimistic locking scheme works there very well, normally the same data isn't accessed for reading that much (unless a subscriber calls to CC with two phones and ask to change his billing address twice ;)

Tanel. Received on Thu Feb 27 2003 - 10:55:25 CST