Re: Sniffing redo logs to maintain cache consistency?

Why don't you try it? You can have an alert for each cache and they won't interfere with one another.(You give them different names.) Since you are using Java on the "client" you can have a thread handle each alert an notify the system when a cache is not up to out of date. The dbms_job can be "polled" as often as 1 / sec but how often do you really need it to run? If it is 1 / sec then on average it will be .5 of a second after the change was committed.

You should give it a try in a simplified environment to understand how it might work for you. You sound like a real whiner. "I can't solve my problem, nothing will work. I can't try anything cause it might not work." Geeze! Try a simple example and see if it will reasonably work. I think your problem is that it isn't complex enough. (not enough testosterone involved) If it is complex its going to break or not perform well.

You need to spend some time analyzing why it isn't working in the current environment before you propose some complex solution. You have to understand where your bottle necks are and why they exist. Until you have a fundemental understanding of your system you are just shooting in the dark.

Jim

--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family.  Remove the negative part, keep the minus sign.  You can figure
it out.
"Andrej Gabara" <andrej_at_kintana.com> wrote in message
news:11a3a163.0302231712.4369046f_at_posting.google.com...


> "Jim Kennedy" wrote:

> > use triggers and have the trigger submit a job to do the notification

see


> > thr dbms_job package.  The job will ONLY run if the transaction is

> > committed - which is what you wanted.  (much simpler and a lot more

> > efficient than the log sniffing idea)

> > Jim

>

> Looks like Oracle polls the job queue in regular intervals. So it can

> take

> a long time after the jobs are submitted to be executed. I also looked

> into

> DBMS_ALERT, but that blocks another DBMS_ALERT call on the same signal

> until

> the previous committed. So I don't think DBMS_JOB nor DBMS_ALERT will

> do

> it for us. Thank's for the suggestion though.

>

>

http://groups.google.de/groups?q=JOB_QUEUE_INTERVAL&hl=de&lr=&ie=UTF-8&oe=UT
F-8&selm=lb4ktugvslni14qtsphorett6jpn0k5nre%404ax.com&rnum=6