Thread: More CORBA and PostgreSQL
With the initial positive response, I dived into the CORBA spec, the
ORBit source, and the PostgreSQL source. I have good news to report.
- CORBA and PostgreSQL were made for each other. The designers of the CORBA
architecture had object oriented databases (OODB) in mind as one of the
standard implementation of objects. E.g.:
"An ORB may have access to multiple Interface Repositories. This may occur because...an object implementation (such
asan OODB) prefers to provide its own type information..."
So, implementing CORBA for PostgreSQL is simply a matter of following the
very clearly designed architecture.
- CORBA is extremely modular with well-defined interfaces between components.
This means that it should be possible to write generic CORBA glue for
PostgreSQL that could work with any ORB.
- The ORBit sources appear to be LGPL'ed, which means they can be linked to
PostgreSQL without poisoning the BSD license.
I also have bad news to report.
- Most of the CORBA functionality that PostgreSQL would rely on is currently
unimplemented in ORBit.
- 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.
-Michael Robinson
Just to add my bit to this: Although I haven't looked into it yet, but I've come across a book describing how to use CORBA with Java, and JDBC. I'm going to try to get this book, and see how this could work. On Fri, 13 Nov 1998, Michael Robinson wrote: > With the initial positive response, I dived into the CORBA spec, the > ORBit source, and the PostgreSQL source. I have good news to report. > > - CORBA and PostgreSQL were made for each other. The designers of the CORBA > architecture had object oriented databases (OODB) in mind as one of the > standard implementation of objects. E.g.: > > "An ORB may have access to multiple Interface Repositories. This may occur > because...an object implementation (such as an OODB) prefers to provide > its own type information..." > > So, implementing CORBA for PostgreSQL is simply a matter of following the > very clearly designed architecture. > > - CORBA is extremely modular with well-defined interfaces between components. > This means that it should be possible to write generic CORBA glue for > PostgreSQL that could work with any ORB. > > - The ORBit sources appear to be LGPL'ed, which means they can be linked to > PostgreSQL without poisoning the BSD license. > > I also have bad news to report. > > - Most of the CORBA functionality that PostgreSQL would rely on is currently > unimplemented in ORBit. > > - 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. > > -Michael Robinson > > -- Peter Mount, IT Section petermount@it.maidstone.gov.uk Anything I write here are my own views, and cannot be taken as being the official words of Maidstone Borough Council
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
> 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... If someone were choosing an ORB, they perhaps could look at whatever the Gnome project chose (either mico or ORBit, can't remember which). Also, they didn't consider ILU because of licensing considerations, but the license changed very recently and I think would now be a strong candidate... > > ... 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. The PG backend is neither reentrant nor threadsafe, and isn't likely to become so soon (several/many places where global variables are used, etc). However, with the existing "forked model", there is a separate backend for each client, so (if I understand things a bit) the trick will be figuring out how to call a single routine which will give access to a client (as happens now) but without handing off through a socket/IP connection. - Tom
On Fri, 13 Nov 1998, Thomas G. Lockhart wrote: > > 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... > > If someone were choosing an ORB, they perhaps could look at whatever the > Gnome project chose (either mico or ORBit, can't remember which). Also, > they didn't consider ILU because of licensing considerations, but the > license changed very recently and I think would now be a strong > candidate... Why what Gnome chose vs what KDE is going with? *braces for political discussions* *grin* Then again, isn't the point of ORBs that you don't have to pick one...? Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Why what Gnome chose vs what KDE is going with? *braces for
> political discussions* *grin* Then again, isn't the point of ORBs
> that you don't have to pick one...?
I lurk on the gnome mailing list because they are using SGML/DocBook for
their docs efforts, as we are. Don't know if what they chose is the same
as what KDE is using (assuming that KDE is using Corba stuff). afaik the
Gnome vs KDE discussion has been centered around the QT (graphics?)
licensing issue.
You do have to choose an ORB to work with (though perhaps it can be
fairly straight-forward to switch to another). However, the ORB you
choose should be able to interoperate with other ORBs on the wire, so
you can mix and match clients and servers developed separately with
different ORBs.
- Tom
On Fri, 13 Nov 1998, The Hermit Hacker wrote: > political discussions* *grin* Then again, isn't the point of ORBs that > you don't have to pick one...? One what? As yet no one has said that an ORB is/does or what the letters stand for, or what Corba is/does or what that stands for. It might be nice if some one mentioned in simple terms just what is all the about, and what does it do? Thanks Totally clueless Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 ------------------------------------------------------------------- Success Is A Choice ... book by Rick Patino, get it, read it!
Terry Mackintosh wrote: > On Fri, 13 Nov 1998, The Hermit Hacker wrote: > > > political discussions* *grin* Then again, isn't the point of ORBs that > > you don't have to pick one...? > > One what? > As yet no one has said that an ORB is/does or what the letters stand for, > or what Corba is/does or what that stands for. Common Object Request Broker Architecture > It might be nice if some one mentioned in simple terms just what is all > the about, and what does it do? Basically it is a standard way for objects written in different languages to communicate with each other. Mark Bedish mark@gwsi.com
On Fri, 13 Nov 1998, Mark Bedish wrote:
> Basically it is a standard way for objects written in different languages to
> communicate with each other.
My understanding is that it goes one better then that
even...objects written in different languages on different platforms and
operating systems..
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, Nov 13, 1998 at 02:49:53PM +0000, Thomas G. Lockhart wrote: > If someone were choosing an ORB, they perhaps could look at whatever the > Gnome project chose (either mico or ORBit, can't remember which). Also, Gnome switched from mico to ORBit for performance reasons. Michael -- Dr. Michael Meskes, Manager of the Western Branch Office, Datenrevision GmbH work: Cuxhavener Str. 36, D-21149 Hamburg home: Th.-Heuss-Str. 61, D-41812 Erkelenz, Michael.Meskes@usa.net Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!
On Fri, Nov 13, 1998 at 07:35:00PM +0000, Thomas G. Lockhart wrote: > I lurk on the gnome mailing list because they are using SGML/DocBook for > their docs efforts, as we are. Don't know if what they chose is the same > as what KDE is using (assuming that KDE is using Corba stuff). afaik the > Gnome vs KDE discussion has been centered around the QT (graphics?) > licensing issue. Yes. There are ugly discussions going on. The problem with KDE is that they happily incorporated GPLed code and linked it against qt, which RMS claims is illegal. Michael -- Dr. Michael Meskes, Manager of the Western Branch Office, Datenrevision GmbH work: Cuxhavener Str. 36, D-21149 Hamburg home: Th.-Heuss-Str. 61, D-41812 Erkelenz, Michael.Meskes@usa.net Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!