pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedtransactions in libpq++ require new connection?
2+ messages / 2 participants
[nested] [flat]
* transactions in libpq++ require new connection?
@ 1999-07-08 19:55 George Young <gry@ll.mit.edu>
0 siblings, 1 reply; 2+ messages in thread
From: George Young @ 1999-07-08 19:55 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [INTERFACES] transactions in libpq++ require new connection?
@ 1999-07-09 01:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: George Young <gry@ll.mit.edu>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 1999-07-09 01:20 UTC (permalink / raw)
To: George Young <gry@ll.mit.edu>; +Cc: pgsql-interfaces
George Young <gry@ll.mit.edu> writes:
> Currently, the PgTransaction class only has a public constructor which
> opens a new connection to the DB, and closes it on commit.
Ugh. I agree that's pretty awful.
> 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...
Actually, I think the cleanest design would be to have a commit() member
function. If the object is destroyed without having committed, the
default behavior ought to be to abort (rollback), not commit. The
reason I think this is that if you imagine a PgTransaction object that
is local to a function, and the function is exited by an exception,
you probably want abort to happen rather than commit.
There might be some cases where you'd rather it worked the other way
around --- if so, we could have a constructor option to set the default
behavior at destruct time. But I think defaulting to abort would be the
safest behavior for a program that uses exceptions.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1999-07-09 01:20 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-07-08 19:55 transactions in libpq++ require new connection? George Young <gry@ll.mit.edu>
1999-07-09 01:20 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox