Database replication problems.

[Ashfaq R. <as...@co...>]

> From own...@lu... Wed May  1 22:08:33 1996
> Subject: Re: any experience with  arsperl
> To: ar...@lu...
> In-Reply-To: <199...@su...> from "Ashfaq Rasheed" at May 1, 96 03:06:02 pm
> X-Mailer: ELM [version 2.4 PL23]
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset=US-ASCII> 
> Content-Transfer-Encoding: 7bit
> Sender: own...@lu...
> Precedence: bulk
> Reply-To: ar...@lu...
> Content-Length: 471
> X-Lines: 13
> 
> >	Has anybody already used this module for a major development. Any 
> >know bugs or any tips that somebody can give me. This is becoz I am planning
> >to use it for one upcoming project. 
> 
> 
> well, we certainly did :)
> 
> we used it for performing imports of data from other databases when it
> wasn't convenient to use arimport. we also use it for API backend programs
> launched from filters as it got tedious to use C for somethings that can
> be done in a few lines of Perl.
> 
> jeff
> 

I don't know whether this is the right place to ask this question but I am
sure many of you out there will have my answer for my questions. So please
respond directly to me if this is not relevent to this list.

The project that I am planning to use this module is something like this:

We are using Remedy for our help desk. Recently we made some operational changes
in the help desk. Now if a user has a complaint a ticket might be opened 
in Remedy or in another database (offsite not connected to our network) 
depending on many other factors. 

Therefore a project: Synchronize both databases.

If a ticket is opened or modified in Remedy send an email to other database and
the other way around if the ticket was opened or modified send it to Remedy.

We outlined what might be called a handshake protocol. For every mail sent there
should be an acknowledgement.

To open a new ticket is not of any problem, it is the update.

Update problems:

1. 	Recursive updates. Database A makes an update and sends a mail to
	database B. Database B makes that change and sends it to Database A.
	The cycle continues. 
	This might also be trivial, attach the origin of the update. Am I
	missing something?

2. 	Multiple (or concurrent) updates in a short period of time. 

	A. Update is made in database A and it sents a message to database B.
	   Around the same time an update is made in database B which sends a 
	   message to database A.
	   - Now both the databases are out of synch.
	   We thought about sending a before and after state of the data but
	   looks like doesn't seems to work.

	B. More then one update occurs in database A within a short period of
	   time. (Belive me on this. Email is the way we will be going for now. 
	   No other choice.).  And my trustworthy email system sends the
	   updates out of sequence. (Have sequence numbers?. Check the last 
	   modified time_date fields?)

Along with all the data fields in the Email we have also these.
	Message type: 	1. New Ticket
			2. Update.
We are ready to add any more fields to the email.

Any ideas, pointers, tips given will be very much appreciated.

-thanks
ashfaq