Re: OPS and read synchronization

What you are seeing is possible if the second query happens too fast. It is an effect that is not usually visible, but does exist. If the query occurs in one node shortly after the other node updates, then the commit may not have had time to propagate, and reads will go out of synch.

The relevant parameter is

    max_commit_propagation_delay
which defaults to 700, and is measured in hundredths of a second. Consequently a
query at one node that takes place within 7 seconds of a committed update at another node MAY not see the update. (Note, on busy systems, there is likely to be so much other messaging going on, that the commit could easily propagate far ahead of the 7 second limit).

I have not yet tested for side-effects of reducing the max_commit_propagation_delay.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Now running 3-day intensive seminars
http://www.jlcomp.demon.co.uk/seminar.html

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases


gadams wrote in message ...


>We are running OPS 8.17 on a sun/Solaris cluster and we are having a

problem


>with read synchronization.  OPS is configured as a shared disk between two

>machines in the cluster.

>

>Process one (p1) is connected to one of the OPS machines (ops1).  It

>performs an update and commit, and then notifies a different process (p2)

>that it has completed the transaction.

>

>P2 is connected to the other machine in the cluster (ops2).  When it does

>the read, it does not seem to be getting the data from the update that p1

>posted.

>

>Is the above  possible in an OPS environment?  Does OPS have to be

>configured is a particular way to avoid the above.

>

>

>