Типичное решение, как уже говорил Андрей Панфилов , это использовать select for update skip locked:

1. tx1 залочила запись
2. tx2 в нее упирается, видит что та залочена и просто идет к следующей записи

Мы наверно хотим чтоб каждый поток работал только над одной задачей, поэтому еще про limit/rownum не забываем.
Timein1. Не будет ли у меня ситуаций, что я апдейчу уже обновленную строку? Использую Оракл, и насколько я знаю, у него по умолчанию Read committed.Проблема в том что ты сможешь сделать одновременный select. И два потока будут работать над одной задачей. Обновления сами по себе конфликтовать не будут, кто первый - того и тапки:
1. tx1 обновит запись, меняет state на 'UPDATE'
2. tx2 заблокируется на этой записи пока tx1 не закончится
3. tx2 наконец-таки разблокируется, однако у записи уже state поменялся, поэтому условие and state = 'READY' пропустит эту запись и ничего не обновит.

Т.е. and STATE='READY' в данном случае сработает в качестве оптимистической блокировки. Обратно в Java прийдет что кол-во обновленных строк=0, ну и соответственно все наделанные изменения можно будет тоже откатить.

Но! Т.к. у тебя Oracle, то как обычно все сделано через одно место.. С одной стороны хочется вытащить только 1 запись, с другой стороны rownum не решает эту проблему, т.к. он будет считать как заблокированные, так и не заблокированные записи . Соответственно если просто сделать where rownum=1, то мы наткнемся на заблокированную запись и просто остановимся не вернув ничего. Если же делать where rownum <= N , то в большинстве случаев будут блокироваться больше одной записи. Но если все-таки уметь обрабатывать задачи не по одной, тогда все норм.

Timein , я не думаю что там есть глубокая мысль, просто Petro как обычно не понимает проблему. У тебя вполне типичная задача, специально для ее решения создан select for update skip locked . Это прям применение "по книге".