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
undertakingand 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
haveto be rewritten for every  ORB. If you want to do this I suggest starting with  ORBit since it is all C and thereby
easierto slap  onto PgSQL.
 

3. Extend postmaster to proxy CORBA requests.  Postmaster could fork of postgres processes  on incoming connections.
Postmasterwill 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!