You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by arun philip <ph...@gmail.com> on 2012/08/23 18:40:56 UTC
SQL Transactions History (Creating a cache file)
Hello,
I am currently working on a project on heterogeneous database
synchronization.
I am using Derby as one of the databases.
As my design is to employ SQL Transaction based synchronization, I need to
create a file which maintains all the required SQL statements (Create,
Insert, Update, Alter and Delete).
Can you please tell me which is the source code file I can use to filter
and write all the required SQL statements.,
Regards,
Philip Jacob
Re: SQL Transactions History (Creating a cache file)
Posted by Rick Hillegas <ri...@oracle.com>.
On 8/23/12 9:40 AM, arun philip wrote:
> Hello,
>
> I am currently working on a project on heterogeneous database
> synchronization.
> I am using Derby as one of the databases.
> As my design is to employ SQL Transaction based synchronization, I
> need to create a file which maintains all the required SQL statements
> (Create, Insert, Update, Alter and Delete).
> Can you please tell me which is the source code file I can use to
> filter and write all the required SQL statements.,
>
>
> Regards,
>
> Philip Jacob
Hi Philip,
As you probably know, heterogeneous synchronization is complicated by a
number of problems, including:
1) The different consistency and correctness models of the different
data sources. A change applied to one data source may violate the
consistency and correctness checks at another data source.
2) The different datatypes of the different data sources. A change
applied to one data source may be truncated or over/under-flowed at
another data source.
These are only the simplest examples of the problems which arise in
heterogeneous synchronization but they give rise to the following
alarming behavior: over time, the data at the different data sources
diverges and the divergences tend to compound and get worse. I trust
that you have given some thought to how you will limit your exposure to
these problems and how you will bring the data sources back into
agreement periodically.
Having said that, a good place to start with Derby is to look at the
replication subsystem. Derby uses log-based replication, a technique
also used by many synchronization subsystems. There are many hard
problems to solve, but the replication subsystem should be a good place
to start.
Hope this helps,
-Rick