More CORBA and PostgreSQL
От | Michael Robinson |
---|---|
Тема | More CORBA and PostgreSQL |
Дата | |
Msg-id | 199811130536.NAA19505@public.bta.net.cn обсуждение исходный текст |
Ответы |
Re: [HACKERS] More CORBA and PostgreSQL
Re: [HACKERS] More CORBA and PostgreSQL |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: