I investigated further.
With Oracle Driver 10.2.0.4.0, the XAER_NOTA is "translated" by the driver to an XAER_RMFAIL, so JBossTS rises an exception.
Oracle Driver 220.127.116.11.0, instead, preserves the XAER_NOTA, so the return value of the commit issued on the XAResource (in com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit()) is XAException.XAER_NOTA: the _recovered field is false, so the method returns TwoPhaseOutcome.FINISH_ERROR. The calling method, com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(boolean, AbstractRecord), then adds the corresponding recordlist to the failedList (line 3205 of BasicAction; I'm using JBossJTA 4.5.0 GA), but then it returns TwoPhaseOutcome.FINISH_OK. From that point on, the commit seems to be ok, but I can't see any further processing of the failedList. I don't know if this is a problem or not.
Please note another important fact. The resources that cannot be committed in my case are all "read only" resources (the commit is issued by line 2159 of com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(boolean)). Maybe this is the reason for which JBossTS doesn't care to process the failedList.
So you might be wondering why I disabled the readOnlyOptimisation and I'm committing read-only resources. The reason is issue JBTM-492, which is described here:
Because I can't wait for JBossTS 4.6.0GA to be available, I had to disable that optimisation. However, this causes the problem I'm describing with Oracle.
So, my questions are:
1) can I ignore the fact that the commit of readonly resources fail with XAER_NOTA and the consequent JBossTS warnings? Or should I better re-enable readOnlyOptimisation and patch JBossTS by myself to resolve issue JBTM-492?
2) why do you think Oracle is complaining when committing readonly resources and it is returning XAER_NOTA instead of XA_RDONLY?
The failed list is driven through the recovery subsystem.
You'd have to talk with Oracle about their use of NOTA versus RDONLY.