When you have a particularly thorny problem with WebObjects, you may want to back up a step, because the problem you're having may be one of architecture, not the particular symptom you're experiencing.
A couple of times I've been asked:
How do you handle an optimistic locking failure?
The question always makes me cringe, because if you're asking that question, you have a schema problem, not a problem with WebObjects; you're asking the wrong question. The optimistic locking failure you're trying to work around is a symptom of a system problem. You need to back up a step and look at the bigger picture.
The real question you should be asking yourself is: Why do I have multiple processes trying to write the same piece of data at the same time, and what can I change the schema to prevent that?
If you ask yourself that question, you may find that the right answer for dealing with the error is actually to turn off the columns WO is locking on, because if your system is correctly designed, then the right answer to an optimistic locking failure is:
1. Failure. The failure is correct.
2. Ignore. The system can robustly handle duplicate changes.
3. Transactions. WO and databases support transactional changes, use them.
I have yet to see a system where dealing with the optimistic lock after it happened was the right answer.