Networking error leads to orphaned transaction?

[flarosa]

Background: We've been successfully using Authorize.net on a very active web site since 2015. Our server is written in Java and we're using the provided Java SDK.

Recently, we became aware of a case where a customer's credit card was charged, but their order was not processed. When we investigated the problem, we found these messages in our logs:

2022-04-15 15:07:48,991 Http request execute failed: 'Read timed out'
2022-04-15 15:07:48,992 Adding ErrorMessage: Code: 'java.net.SocketTimeoutException', Text: 'Read timed out'
2022-04-15 15:07:48,992 Invalid response:'net.authorize.api.contract.v1.ANetApiResponse@443cfbdf'
2022-04-15 15:07:48,992 [Read timed out]

What we think happened is that we posted a CreateTransactionRequest which was received and successfully processed, but while our server was waiting for a response, there was some kind of network outage or failure that caused us to get a SocketTimeoutException.

As you might imagine, our code is set up to catch exceptions during payment processing and when one is caught, it rolls back its database transaction and tells the user that the transaction failed.

Can what I describe happen? If it did happen this way, would the Authorize.net side still let the payment go through? 

Thanks,

Frank

[SandraLewisFrin]

Orphaned transactions and distributed deadlocks happen when there is a session established to the database without any current running requests, but there was a request (one query or more) that holds locking on database object(s).

Orphaned transactions can cause a lot of locking and blocking on the database, and usually it is related to the application and how it is code is written “badly” or in a way that meets the atomicity of the transactions: "commit all or rollback all".

[VictorJohnsonan]

When I upgraded a 1.2GB wallet.dat from 1.4.0 to 1.5.0, I instantly observed HUGE delays in JSON RPC (over 30 seconds per query). During the 30 seconds, the wallet was constantly flushing and writing 250MB/sec IO to disk (SSD based). This essentially made it completely useless to run as a pool wallet as I was only getting 2-3 payouts per minute (thanks RPC), and since MPOS (frontend) uses RPC for dashboard data, it was causing 30 second page load times (and im most cases, page load failures).

[joseemily]

Hey,

In order to mark this as an orphaned, distributed transaction SPID, SQL Server changes the SPID from a positive number to the counting for that issue.