Re: Re: libpq++

Поиск
Список
Период
Сортировка
От Justin Banks
Тема Re: Re: libpq++
Дата
Msg-id 15089.45940.490466.456420@idoru.tricord.com
обсуждение исходный текст
Ответ на Re: Re: libpq++  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-interfaces
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
 Tom> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> I think he is creating his own shared memory area:
 Tom> Oh, I see.  Isn't that pretty silly, considering that there's no way Tom> for such objects to share a
DBconnectionif they are in different Tom> application processes?  Seems like a simple static variable would do Tom> the
jobjust as well with a lot fewer portability and resource-leakage Tom> issues...
 

If you have a class, say 'class host', that represents a table in your
database, in which you are storing host information, and you want each host to
also be a database object, you now have two choices, as far as I can tell. You
can connect to the database in the chain of constructors somewhere, or you can
put it off until you actually issue a query of some kind. Either way, you get
punished quite severely if you want say, a 

int N = 75;
host * cluster_of_boxes = new host[N](default_parameters_of_some_kind);

since you either then have N connections to the backend, or every time you
want to go to the DB you take a big hit. With my modification, you only get
one connection to the backend, and all your host objects share it. 

You're right - this only works because the shared connections all occur in the
same address space. It doesn't buy you anything between applications, only
inside an application. The problem is that there's no way for different
instantiations of classes inheriting database-ness from the PgDatabase class
to share a PGconn* unless the PgDatabase class provides a way for different
instantiations to know that existing connections are available.

-justinb

-- 
Justin Banks Tricord, Inc. justinb@tricord.com
"The time you enjoy wasting is not wasted time."  - Bertrand Russell


В списке pgsql-interfaces по дате отправления:

Предыдущее
От: Keith Millard
Дата:
Сообщение: Postgres odbc driver bug
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PyGreSQL: setup.py is broken in RC1