Subject | [firebird-support] Re: Database replication - problem with uncommited transactions. |
---|---|
Author | Svein Erling Tysvær |
Post date | 2010-03-25T12:06:38Z |
>I have MULTIPLE destination databases and my central repository sendsHi Francisco! Why not have a SENT_AUDIT_RECORDS table (containing the PK of the record and the ID of the destination database) rather than SENT_AUDIT_RANGES? I just think it is simpler to work with Firebirds concurrency rather than against it. Or is there a logical reason for making uncommitted records prevent committed records from being transferred?
>and receives data to and from every destination.
>I can't delete audit records after sending them. I could delete them
>only after every destination has received those records.
>When a destination receives a range of audit records, I save the first
>and last pkey of the range on a SENT_AUDIT_RANGES table, with an id of
>the destination database.
>If inside that range there were uncommited records(audit records get
>their primary key from a generator) during the sending transaction,
>those records will never be sent, since that range will be marked as
>sent.
>So, chronology is relevant because I should only send audit records
>previous to the first uncommited audit record.
Set