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

"Tanel Poder" <tanel@@peldik.com> wrote:
> 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).

Isn't it most likely already in the cache? If not, what is the cache doing?

> 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.

I agree it can easily be done. But I don't think it's desirable to send these errors all the time.

> 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.

Forget about changing stuff for now, because first off I want to see stuff. I want what I see to be accurate. If the database changes things without telling java, and java shows me data from the cache, then what I see will not be accurate. Now if I try to change it, it will become accurate and let me know, but I don't want to have to try to change everything I see just to make sure it is accurate.

> > 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?

No, I'd prefer not to use in-Java caching in the first place (or for that matter, not to use Java in the first place)

> 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 ;)

That sounds fine, but I don't see what it has to do with the OPs concerns.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service              New Rate! $9.95/Month 50GB