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