--On Donnerstag, M?rz 30, 2006 19:10:06 -0300 Marco Canderle 
<marcocanderle at gmail.com> wrote:
> As I said, Reads are solved locally by every local slave server, and
> writes are routed directly to the master server, which then replicates
> the changes made.
> Here is where my problem arise. If a user is connected to a slave server
> and needs to make changes to de database, the writes will be passed to
> the master server. The master will make the corresponding changes and
> Slony-I will replicate this changes back to the slave who passed the
> writes (and all other slaves). All this steps adds a delay until the
> remote user can see the changes he/she made to the database reflected in
> his screen. For example if the user adds a new product to the database,
> he won't see it in the products list until  the replication takes place.
> This kind of situations can make the system show wrong information, which
> is dangerous in some scenarios of my system.
>
> So I ask: Are there any solutions that may help me reduce/avoid this
> delay or at least prevent the slave server to respond to the user until
> the replication have propagated to all the slaves (or at least the one
> which originates the writes)? Maybe some kind of combination between
> asynchronous replication (provided by Slony-I) and synchronous
> replication?

For once, you can reduce the interval slony uses to synchronize the updates 
around, no idea how the options are named, only twiddled with them a bit a 
time ago. This could reduce the delay, but would not remove it.

I am not aware of a solution within slony, yet I can easily think of an 
architecture which might do what you want:
Before every write, make the writing process first insert the row into the 
master server, insert a "object is dirty" row into a special table _at 
every satelite location_ and commit at the satelites, then commit the 
master. This way, the information that a row is dirty is known at every 
satelite server.

You could then either connect a slightly modified slony-replication to your 
satelite server which instead of syncing does remove the marker rows (we 
did something similar at our company for other purposes). Or you could 
(which I'd clearly prefer, include the transaction id within your marker 
rows. If your client then requests a row from the local database it would 
need to have a look into the special table and could then say something 
along the lines of "object is currently being edited"...

If the connection goes down, well writing gets impossible, but that's the 
case anyhow... And of course your local data gets non-up-to-date, well no 
way to change that. At least it should make conflicting updates impossible.


Mit freundlichem Gru?
Jens Schicke
-- 
Jens Schicke		      j.schicke at asco.de
asco GmbH		      http://www.asco.de
Mittelweg 7		      Tel 0531/3906-127
38106 Braunschweig	      Fax 0531/3906-400