It is the distribution database that does most of the work in a replication.The subscriber receives the changed data from the distributor. It is possible to have a configuration where the subscribers also can make changes to the data. The changes made by the updating subscriber are then sent to the publisher, onto the distributor, and then onto the other subscribers.
Without immediate updating, your changes are only committed to the local subscriber, and queued for distribution back to the publisher, and following that, the other subscribers.
In both cases there is a period of time when a stale record is still at the other subscribers, and one of those subscribers may update the stale record and cause a conflict.
To paraphrase the quoted block, with immediate update the only guarantee is that the commit is immediately updated to the publisher.
The changes will be sent to the other subscribers in due course.
The publisher contains the articles or objects that are to be published.
The distributor contains the data that is to be changed and promulgated.
I was able to setup replication properly and it came in sync normally.
But when user tried to insert new records at subscriber I got primary key violation errors for lot of tables.
All replication operations are based on the principle that the changing of data on one data source is followed by the reproduction of that new data on one or more additional distributed locations.