| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: tab completion for prepared transactions? |
| Date: | 2010-01-24 19:52:55 |
| Message-ID: | 4B5CA517.1050105@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> What is the
> difference between a transaction manager and an application that opens
> multiple connections and does PREPARE + COMMIT PREPARED across them?
It's what happens if your application crashes after issuing the PREPARE.
A correctly configured transaction manager will know to reconnect to all
the resource managers (ie. databases), check its own transaction log,
decide which global transaction have committed, and issue the
COMMIT/ROLLBACK PREPARED commands to the resource managers to finish the
global transactions.
Sure, you can do all that in an application too, but I have yet to see
one that does (correctly). At the point that you do, you can say that
your application has a built-in transaction manager. Really, if you know
what you're doing, you'll know that note in the manual doesn't apply to you.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Baron Schwartz | 2010-01-24 19:54:33 | Re: MySQL-ism help patch for psql |
| Previous Message | Heikki Linnakangas | 2010-01-24 19:45:15 | Re: tab completion for prepared transactions? |