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(at)hub(dot)org secondary: scrappy(at){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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

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