Re: [HACKERS] CORBA STATUS

I have done some research into slapping
a CORBA interface onto the PgSQL server.
I have looked at ORBit but my findings 
seems to apply to most CORBA implementations.

I found that there is a fundamental problem
concerning the difference in process models
in pgsql and the POA (Portable Object Adaptor)
in CORBA implementations.

AFAICS, POA assumes a threaded server while
PgSQL uses a traditional forking model.

I see 3 ways to resolve this:

1. Adapt the PgSQL server to use threads instead of forking.
   I am not sure we want to do this since it is a major
   undertaking and will not help the rock solid stability
   we expect from a professional RDBMS.

2. Write a Forking Object Adaptor (FOA).
   Would be a big job but it would benefit other similar
   projects. A FOA would have to be rewritten for every
   ORB. If you want to do this I suggest starting with
   ORBit since it is all C and thereby easier to slap
   onto PgSQL.

3. Extend postmaster to proxy CORBA requests.
   Postmaster could fork of postgres processes
   on incoming connections. Postmaster will keep 
   listening and proxying request and responses 
   to/from the postgres process through some kind
   of IPC. This will make the postmaster multithreaded 
   and the postgres processes still singlethreaded.

It is doubtful if the gains:
- standard-based protocols
- less code to maintain (?)
justifies the amount of work required.

An easier way out is to, as suggested by others,
implement the CORBA-service outside the server
itself. It will in some cases give some latency
related performance degrading compared to a 
in-server implementation.

One effort to do something like that
(and more) is gnome-db. Check out
http://www.gnome.org/gnome-db/

regards,
-----------------
Göran Thyni
On quiet nights you can hear Windows NT reboot!