Re: [HACKERS] More CORBA and PostgreSQL]

On Fri, Nov 13, 1998 at 09:00:14AM -0400, The Hermit Hacker wrote:
> On Fri, 13 Nov 1998, Michael Robinson wrote:
> 
> > - The ORBit sources appear to be LGPL'ed, which means they can be linked to
> > PostgreSQL without poisoning the BSD license.
> 
>     Mico is also LGPL'd for the libraries...
> 
> > I also have bad news to report.
> > 
> > - Most of the CORBA functionality that PostgreSQL would rely on is currently
> > unimplemented in ORBit.
> 
>     I don't know what is implemented, but check out:
> 
>     http://www.vsb.cs.uni-frankfurt.de/~mico
> 
>     They "claim" a completely 2.2 Corba implementation...
> 
> > - While CORBA provides a very disciplined interface for allowing different
> > object implementations (e.g. Python and PostgreSQL) to share the same address
> > space and execution context safely and efficiently, the PostgreSQL backend
> > doesn't seem ready for it.  In particular, it doesn't appear to be thread
> > safe.  It may not even be reentrant, from what I can tell.  And, if a backend
> > process is not punctual about reading cache synchronization messages out of
> > the IPC queue, it appears that excessive cache invalidation would hurt
> > performance.
> 
>     Hrmmm...does this mean that we are going to have to move towards a
> threaded model vs forked?  Or is it just going to require some major code
> cleanups for the 'thread safe/reentrant' as aspect?
> 
> Marc G. Fournier                                
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 

OK, here as another viewpoint.

Don't even think about MICO.  Its design goals are pedagical.  It is
very slow, very, very compiler hungry, and has no collocation 
optimization.

ILU is multi-language, and GPL uncontaminated.  It seems to be
under development by a very small team.  They just released the
13th alpha.  a12 to a13 was roughly a year.  You need to be 
prepared for relatively slow code development, with code changes
visible only at release points.

ORBit is C only, which was very important to the GNOME group.
Having worked in C under ILU, I have come to think this a 
large mistake; working to overcome the hysterisis gets to be
very irritating, and checking for exceptions is a real pain.
Also, ORBit is a bare ORB with no services and not much 
documentation.  

Another option I have seen no discussion of is TAO.  Fast, aggresive
development.  CVS available, fair service support.  Built on underlying
library.  Essentially C++ only (some Java support).  See 
http://www.cs.wustl.edu/~schmidt/.  This is also not GPL.

I am assuming that you have looked at OmniORB and rejected it for
GPL reasons.  If not, you should also consider it.

Finally, I am not sure about the threading.  It may be easier to think
about caching less and more about quick startup.  It is not clear to
me that having a thread-safe agent managing a pool of forked backends
is inherently that much slower, and in many applications (like a
Web fronted one) is clearly a great improvement in terms of
memory usage.  Of course, if cache invalidation is such a large
performance loss, the agent could attempt to minimize the effects
by employing user affinity, or even better, if parsinng is easy
enough, by relation affinity.

What I would find intereting about this appoach has not been touched
on.  It should make building a distributed database very easy.

Ah well, I don't have the time, and maybe not the talent to do the
work, so I will shut up and let you guys get back to the very well
done task of enhancing postgresql.

Thanks

Jim






Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


----- End forwarded message -----