RC: 73 A connection with a remote socket was reset by that socket

"Many times this issue can be seen in firewall environment and has been seen with network DNS problems and/or network config problems. One of the most common is when a passive device (router, switch, hub, etc.) is in between the client & the server. If the port on the passive device is set to Auto-Negotiate, it will automatically defer to the active device (the NIC in the client) to set the connection speed. If the NIC is also set to Auto-Negotiate (default in most OS's) this often causes excessive delays and interruptions in connectivity. This is because the NIC is looking to the network appliance to set the connection speed and vice-versa, it takes some time before the network device will find a suitable connection speed (not always optimal, just suitable) and begin data transfer. This repeats every time a data packet is sent across the network. While the negotiating period is relatively short by human standards (usually in the nanosecond range) it adds up over time when trying to send a large amount of data at a high speed and causes the connection to be broken. The best work around for that is to hard code both the NIC and the network port for a specific setting. This is usually 100Mb Full Duplex for a standard CAT-5 copper connection, although older equipment may require reconfiguration of 10/100 NICs to allow for that speed. Another possible workaround for this issue is to estimate the file transfer time and increase the IDLETIMEOUT to a level higher than that time."

IBM

Recuperación de transacciones Oracle en WebSphere (AS) 8.5

En el momento de iniciar el servidor de aplicaciones después de una caída, éste intenta recuperar las transacciones de base de datos correspondientes a data sources XA. Con una base de datos Oracle en ocasiones se presenta la siguiente excepción:

0000048 XARminst E WTRN0037W: The transaction service encountered an error on an xa_recover operation. The resource was com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@e0881a27. The error code was XAER_RMERR. The exception stack trace follows: javax.transaction.xa.XAException at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:709) at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.recover(WSRdbXaResourceImpl.java:1116) at com.ibm.ws.Transaction.JTA.XARminst.recover(XARminst.java:141) at com.ibm.ws.Transaction.JTA.XARecoveryData.recover(XARecoveryData.java:716) at com.ibm.tx.jta.impl.PartnerLogTable.recover(PartnerLogTable.java:431) at com.ibm.tx.jta.impl.RecoveryManager.resync(RecoveryManager.java:1534) at com.ibm.tx.jta.impl.RecoveryManager.performResync(RecoveryManager.java:2267) at com.ibm.ws.tx.jta.RecoveryManager.performResync(RecoveryManager.java:117) at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:2220) at java.lang.Thread.run(Thread.java:773)

El problema se debe a que el usuario de base de datos que estamos usando no tiene permisos para recuperar transacciones, lo que se solucciona ejecutando lo siguiente:

grant select on pending_trans$ to <user>;
grant select on dba_2pc_pending to <user>;
grant select on dba_pending_transactions to <user>;
grant execute on dbms_system to <user>;

Si la versión de Oracle es mayor a la 10.2.0.4, se debe remplazar el último privilegio por:

grant execute on dbms_xa to <user>;

Otra manera de solucionarlo, en caso de que no sea importante recuperar las transacciones (por ejemplo en un ambiente de desarrollo), es borrando el contendio del directorio <WebSphere Application Server_install_root>\profiles\<PROFILE_NAME>\tranlog\<CELL_NAME>\<NODE_NAME>\<SERVER_NAME>\transaction antes de iniciar el Application Server.
Visto en www-01.ibm.com