Re^2: How to safely/atomically process payments

That's insufficient information on all fronts: what code? what input? what output? what conditions are successful? what conditions are unsuccessful? what are the errors?

I think there is. Its a strategy question (what do when remote process wins and local logging fails), not a code question, it doesn't require code

Comment on Re^2: How to safely/atomically process payments

Replies are listed 'Best First'.
Re^3: How to safely/atomically process payments by kcott (Archbishop) on Nov 12, 2013 at 08:43 UTC
Your interpretation of the question clearly differs from mine. That's fine. If the question boils down to: "How do I use SomeApp under certain conditions?", then `SomeAppMonks` (or equivalent) would be a more appropriate place to post the question than `PerlMonks`. On the other hand, if the question boils down to "How do I use Perl to interface with SomeApp under certain conditions?", then `PerlMonks` would be appropriate and the information provided remains insufficient. Let's wait for the OP to clarify this. -- Ken	[reply] [d/l] [select]
Re^4: How to safely/atomically process payments by Corion (Patriarch) on Nov 12, 2013 at 08:50 UTC
I think the problem is still not necessarily related to a specific application. The problem of a half-committed transaction is common, and happens in various locations. My approach would be to lok at how databases usually do their two-phase commit. As I haven't really looked deeply into that, I would write a transaction log before sending the transaction to the remote end, and then either record the success or failure of that transaction, or barring any conclusion of the transaction, diagnose an internal error. This does not provide a magic solution, but it provides a way to determine which transactions need to be manually confirmed.	[reply]