Re: standard interfaces for replication providers

On Tuesday 08 August 2006 17:44, Christopher Browne wrote:
> Most databases that are interesting to replicate are implemented in C
> or C++, thereby implying that a suitably "deep" API needs to be
> implemented in C.
>
> In the case of PostgresQL, at least, operating in Java means that you
> need to operate at "arms length" from the database, which means the
> replication system is by no means tightly integrated.

Yes, PostgreSQL is the tough one here. Having a single-process multithreaded 
PostgreSQL in which PL/Java would run in one global JVM would sure feel like 
Christmas! ;)

Note however that the problem is not Java, but any package that does not 
expect the current PostgreSQL concurrency model. AFAIK Postgres-R has 
same "arms length" architecture with an external process, probably for 
compatibility with Spread.

We have however tried to minimize the inconvenience, even for PostgreSQL, by 
doing the following:
1. Implementation was done in two layers, in which the PostgreSQL-specific one 
is 100% Java-free and feature complete. 

2. High level functionality (i.e. transaction priorities instead of directly 
handling individual lock operations) reduce the number of round-trips to the 
replication process.

3. Event listeners in Java can be registered as non-blocking, thus putting the 
external JVM out of the critical path except in a few critical operations.

Finally, although I concede that most databases that are interesting to 
replicate are written in C or C++, these days, most are also getting tightly 
coupled JVMs fairly high in their feature lists.

-- 
Jose Orlando Pereira