Behavior If Connection to a Database is Lost
During a transaction, it is possible for a client application to lose its connection to the database. Connection loss can be caused by failure of any required resource in the client’s request path, for example, discontinued network connection, host failure, process termination/failure. Without a connection to the database, the state of the transaction that was in progress is unknown.
Loss of a connection causes an exception to be thrown in the client application the next time the client tries to do something that requires the connection. There are a number of exceptions that a client application must be able to handle. They are all derived from the same basic network exception type, which varies according to the driver you are using.
Read-Only Transactions
If the transaction in progress was a read-only transaction then the client application can resubmit the query on a new connection. Because the state of the transaction that was in progress is unknown, the client application does not have the same transaction snapshot. Resubmitting the query on a new connection means starting a new transaction, which means that it is possible that the data being read has changed since the previous transaction was in progress.
Update Transactions
If the transaction in progress was an update transaction then what the client application should do depends on the following:
UPDATE transactions that were in progress when the connection failed are automatically rolled back. Any work done on behalf of the transaction needs to be retried. If the transaction already initiated the commit protocol (either because AUTOCOMMIT was on, or because the user submitted an explicit COMMIT statement), the work might be already durably committed in the system. It is up to the client application to determine whether the transaction was committed.