Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA28231 for ; Thu, 8 Jul 1999 15:56:37 -0400 (EDT) (envelope-from gry@ll.mit.edu) Received: (from smap@localhost) by ll.mit.edu (8.8.8/8.8.8) id PAA21607 for ; Thu, 8 Jul 1999 15:55:09 -0400 (EDT) Message-Id: <199907081955.PAA21607@ll.mit.edu> Received: (from young@localhost) by pansy.llan (8.8.0/8.8.0) id PAA18579 for pgsql-interfaces@postgresql.org; Thu, 8 Jul 1999 15:55:59 -0400 (EDT) Date: Thu, 8 Jul 1999 15:55:59 -0400 (EDT) From: George Young To: pgsql-interfaces@postgresql.org Subject: transactions in libpq++ require new connection? I am using libpq++ with gcc egcs-2.91.66 (egcs-1.1.2 release) on RH linux 5.1 with Postgres 6.5. I need to use transactions to maintain consistency when an application's logical operation actually updates multiple tables. Currently, the PgTransaction class only has a public constructor which opens a new connection to the DB, and closes it on commit. For an application making many short transactions, in an environment with many active clients, this seems to be very wasteful of network and cpu resources. Is there some reason a PgTransaction could not be constructed from an existing PgDatabase (or PgConnection)? Maybe trans should be a lightweight class to avoid problems with inheriting from PgDatabase and thus having to deal with copy/reference-count etc. problems? I know I can roll my own by just Exec("begin"), etc, but having the transaction *committed* (not conn closed) in the destructor would be very handy. Also, there's no rollback member... On yet another note, it would be much neater if the c++ interface would use 'string' type for text args and returns. I'm tired of writing foo.c_str() everywhere... Thanks, George [I'm not too experienced with c++, so I *welcome* any comments/suggestions] George Young, Rm. L-204 gry@ll.mit.edu MIT Lincoln Laboratory 244 Wood St. Lexington, Massachusetts 02420-9108 (781) 981-2756