We have an Java workflow application that uses an Oracle database to track its steps and interactions with other services. During a workflow run several insert/update/selec
"even though the insert/update commit that ran before it completed successfully."
This suggests to me that you are issuing a commit(), and then afterwards expect to read exactly the same data again (that's repeatable read).
This suggests to me that you shouldn't be committing. As long as you want to make sure that NO OTHER TASK is able to modify ANY of the data that you EXPLICITLY EXPECT to remain stable, you cannot afford to release locks (which is what commit does).
Note that while you keep a lock on some resource, other threads will be stacking up "waiting for that resource to become available". The likelyhood of that stack being non-empty at the time you release your lock, gets higher as general system load gets higher. And what your DBMS will conclude when you (finally) issue "commit", is to conclude that, "hey, wow, this guy is finally done with this resource, so now I can go about letting all the other waiting guys try and do their thing with it (AND there is NOTHING to prevent "their thing" from being an update !)".
Maybe there are issues to do with Oracle's snapshot isolation that I'm overlooking. Apologies if so.