幫我找到死鎖

-1

這是我第一次看到這個代碼，我們正在陷入僵局。幫我找到死鎖

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(); 
}

我覺得上面的代碼可以被清理了一下 - 我沒有看到使用這麼多刷新的，但我只是現在使用現有的代碼。

任何人都可以注意到可能導致死鎖的原因？

來源

2011-04-13 TS-

沒有足夠的信息來找到死鎖....會話對象使用的所有函數裏面有什麼？ – 2011-04-13 17:45:50

還有其他交易嗎？ – axtavt 2011-04-13 17:48:23

這不是數據庫中的死鎖，它是等待另一個數據庫會話保持鎖定時的超時。您應該打開Hibernate中的SQL日誌記錄，並在引發異常之前查看您的應用程序正在執行的操作。您還可以使用Oracle的動態性能視圖從數據庫獲取更多信息。例如，從V $ LOCK中選擇以查找當前保持的鎖;您可能需要將其加入V $ SESSION以瞭解有關鎖定持有人的更多信息。

來源

2011-04-13 18:17:33 FelixM

由於例外，我認爲問題不在於此代碼，我認爲這是一個從數據庫中的時間。

順便說一句：你應該重新思考你處理交易的方式。我認爲try{...}finally{trans.rollback);}可能有助於在某些情況下。

來源

2011-04-13 17:48:49 Ralph

幫我找到死鎖

回答

相關問題