(fwd) Re: [HACKERS] More PostgreSQL+CORBA

Andrey Gerzhov (kittle@freeland.alex-ua.com)
Mon, 16 Nov 1998 16:29:47 +0200 (EET)

-- forwarded message --
Path: freeland.alex-ua.com!barmaglot.alex-ua.com!news.alexradio.kiev.ua!not-for-mail
Date: Sat, 14 Nov 1998 10:59:38 +0800 (GMT)
From: Michael Robinson <robinson@public.bta.net.cn>
Message-ID: <199811140259.KAA06678@public.bta.net.cn>
To: tgl@sss.pgh.pa.us
Subject: Re: [HACKERS] More PostgreSQL+CORBA
Newsgroups: alex.gated.pgsql.hackers
Lines: 53
Xref: freeland.alex-ua.com alex.gated.pgsql.hackers:2839

Tom Lane <tgl@sss.pgh.pa.us> writes:
>(I assume CORBA has a recognized standard for the wire-level protocol?)

It's called the General Inter-ORB Protocol (GIOP). It's stream based.
When the streams are TCP/IP sockets, it becomes the Internet Inter-ORB
Protocol (GIOP, plus a specification for addresses, etc.).

>I'm leery of this, not only because of the implementation problems other
>people have mentioned (bringing the backend to a state where it is
>thread-safe would be a large effort),

It may be possible just to put a master lock on the whole backend, so that
only one one thread was active in there at a time.

>but because it subverts all the
>protection and security reasons for having the Postgres frontend/backend
>architecture in the first place. The *last* thing I'd want is client
>code executing in the same process as the database server.

In the general case, I'd agree. However, for specific applications where
you want tight integration with a reasonably well-disciplined system,
such as a language interpreter, it could be a huge performance win. This
is sort of what Oracle did with their Java integration. They wrote a
common-denominator VM, and implemented both PL/SQL, and Java on top of it,
so that both languages could get "raw" access to the database tables.

>However, if I understand things correctly, the CORBA interface will hide
>whether client code is in the same process as the backend server or not;
>so we could each assemble the parts in the way we prefer.

That is exactly correct.

>Does CORBA have any provision for saying "this object is not thread
>safe, don't send it concurrent operations"? If there's something along
>that line, then maybe we don't have to fix the backend before it can
>live in a common address space with the client...

That sort of question is resolved at the "Object Adapter" layer. The
ORBit "Portable Object Adapter" supports two thread policies, "ORB_CTRL_MODEL"
and "SINGLE_THREAD_MODEL" (I don't know the specifics; I just pulled that
out of the Interface Definition for the POA). The Postgres Object Adapter
could, presumably, do whatever it wanted in this regard.

In any case, the full text of the CORBA 2.x spec is here in all it's HTML
glory:

http://www.infosys.tuwien.ac.at/Research/Corba/OMG/corb2prf.htm

I'm really impressed by the quality of the architecture design.

-Michael Robinson

-- end of forwarded message --

-- 
С тем, что не помешает никогда,
                                               Kittle