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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
