Two-phase commit case studies

On Wed, Jul 19, 2017 at 7:10 PM, Gavin Wahl <gwahl@fusionbox.com> wrote:

I've read the documentation for two-phase commit and it sounds interesting, but
I'm having trouble thinking of how to actually put it into production. How are
people using it? Do you use a XA transaction manager or something custom built?
How dos the reconciliation work when a component crashes between PREPARE and
COMMIT? Is anyone using it in the open-source world where transaction managers
are unheard of?

Looking forward to hearing about how two-phase commit has helped you.

One direct use of 2PC, which is for what it has been originally
designed, is to ensure the consistency of a transaction commit across
multiple servers. One thing using extensively 2PC is for example
Postgres-XL (formerly Postgres-XC that introduced the concept), to
commit a transaction across nodes when a transaction involves writes
to multiple nodes.

Postgres JDBC has XA support by the way:
https://jdbc.postgresql.org/documentation/faq.html#xa-support
--
Michael

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Gavin Wahl <gwahl@fusionbox.com> writes:

Hello,

I've read the documentation for two-phase commit and it sounds interesting, but
I'm having trouble thinking of how to actually put it into production. How are
people using it? Do you use a XA transaction manager or something custom built?
How dos the reconciliation work when a component crashes between PREPARE and
COMMIT? Is anyone using it in the open-source world where transaction managers
are unheard of?

Looking forward to hearing about how two-phase commit has helped you.

I use it for holding an advisory lock the duration of any of our several
environment mangling frameworks.

We have fairly complex 1-touch provisioning, decom,
upgrade... rename/relocate/snapshot frameworks.

The lock is used to enforce cooperatively that no one else launches any
of those systems concurrently due to some interesting potential
conflicts.

Thanks

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general