Помоги мне найти тупик

Question

Это первый раз, когда я сам вижу этот код, когда мы заходим в тупик.

Caused by: java.sql.BatchUpdateException: Lock wait timeout exceeded; try restarting transaction

Вот код: (Java / псевдокод)

// This function inside a Job implementation of Quartz Job
execute(...)
{
     UserTransaction trans = getTransaction();
     trans.begin();

     Session session = getSession();

     List<PersistedObject> list = getListOfPersistedObjects(...)

     int counter = 0;
     loop(l : list)
     {
           counter++;

          // this is just sending a message using information based on the object
           sendMessage(l); 

           // Create a 2nd "archive" object based on the data inside the l object
           PersistedObjectArchive archive = new PersistedObjectArchive(l)

           session.save(archive);
           session.flush();

           session.delete(l);
           session.flush();

           if(counter % JDBC_BATCH_SIZE_CONSTANT_FROM_SOMEWHERE == 0)
           {
                session.flush(); // Deadlock Exception happens here
                session.clear();
           }
     }

     trans.commit();
}

Я думаю, чтоприведенный выше код можно немного убрать - я не вижу использования такого большого количества сбросов, но сейчас я просто собираюсь использовать существующий код.

Кто-нибудь заметит, что может вызвать тупик?

Answer 1

Это не тупик в базе данных, это тайм-аут при ожидании блокировки, удерживаемой другим сеансом базы данных. Вы должны включить ведение журнала SQL в Hibernate и посмотреть, что именно делает ваше приложение, прежде чем выдается исключение. Вы также можете использовать динамические представления производительности Oracle для получения дополнительной информации из базы данных. Например, выберите из V $ LOCK, чтобы найти удерживаемые блокировки; вам, вероятно, нужно присоединиться к V $ SESSION, чтобы узнать больше о держателе замка.

Answer 2

Из-за исключения я думаю, что проблема не в этом коде, я думаю, что это время ожидания из базы данных.

Кстати: вы должны переосмыслить способ обработки транзакций. Я думаю, что try{...}finally{trans.rollback);} может помочь в некоторых ситуациях.