abc_daivanraЛучше уж сериализацию через синхронизируемый методчто это такое?
Когда мы вставляем записи с применением select max() + 1, то возможна ситуация, когда 2 разные транзакции
- одновременно получили одно и то же значение select max() + 1. При этом, прочитав значение, они должны обеспечить целостность, поэтому они блокируют вставку из чужой транзакции - если чужая транзакция вставит новое значение, то эта транзакция будет неконсистентна;
- теперь они не могут вставить, поскольку заблокировали друг друга - каждая транзакция ждет, когда другая закончится, чтобы самой вставить, либо выдать ошибку о нарушении уникальности - налицо дедлок.
Выход - использовать для вставки сериализуемые транзакции, или хотя бы использовать сериализуемую транзакцию для обращения к сохраненной процедуре, генерирующей идентификаторы.
Но, поскольку заводить дополнительную транзакцию для вставки хлопотно, проще упорядочить генерацию с помощью synchronized метода (метод можно сделать статическим, либо использовать синглтон). По аналогии с бумажным делопроизводством - каждый по очереди подходит и делает запись в журнале о получении номера.


Конечно, всё это будет работать, если номера получаем только из этого генератора, поэтому, если приложений много, надо организовывать web-сервис, RMI и тому подобное

конечно же,

Как вариант - можно сначала прочитать select max() в первой транзакции, закрыть её, затем открыть вторую транзакцию и уже вставлять с новым вычисленным значением, ловить исключение, пробовать по новой и т.д.
но insert into XXX... (select max() ... from XXX), или просто select/insert в одной транзакции - 100% дедлок, если не обеспечена последовательность