From: | Bret Schuhmacher <bret(at)thelastmilellc(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Suggestions for Remote Procedure Calls from PG, please? |
Date: | 2007-10-18 03:44:33 |
Message-ID: | 4716D6A1.7020900@thelastmilellc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Lane wrote:
>
>
> You've almost figured out the big problem with anything like this;
> the trouble spot is the other way around. What if you launch some
> remote operation, and it succeeds, and then later your own transaction
> rolls back for some unrelated reason? Action FOO did happen in the
> external world, but there is no change in the state of the database
> --- which at the minimum probably means you'll try to do FOO again
> later. Lather, rinse, repeat.
> .
Thanks for the reply, Tom. I was thinking I could have my remote
process send a message back to PG via XMLBlaster, too. XMLBlaster is
a MOM-like message-queuing app that guarantees delivery to
subscribers. (www.xmlblaster.org) The problem, as you stated,
though, is transactional integrity :-(. Hmmm, I'll see about the
to-do queue idea.
Thanks again for your time!
Bret
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFHFtagIeMC5lK637kRAg56AJsF6eNlQWPdpjb8ufiO+xRqZTXymgCfdJFG
4igU9pCasxaVSGOxC0DBbHg=
=qKK2
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | A. Kretschmer | 2007-10-18 04:53:14 | Re: Suggestions for Remote Procedure Calls from PG, please? |
Previous Message | Tom Lane | 2007-10-18 02:55:02 | Re: Suggestions for Remote Procedure Calls from PG, please? |