在現代數據庫系統中長時間保持記錄的常見做法？

問題：在現代數據庫系統中長時間保持記錄的常見做法？在現代數據庫系統中長時間保持記錄的常見做法？

我的理解是在數據庫中鎖定記錄（樂觀或悲觀）通常是在交易過程中很短的時間。

我現在有工作的軟件一直鎖在記錄很長一段時間：

鎖保持在登錄的用戶（在ACTIVE_USERS」表）的記錄用戶登錄軟件的全部時間。
假設用戶A正在處理文件。與該文件相對應的記錄被鎖定，直到USER A保存文件或退出文件。因此，如果一個同事USER B試圖在同一個文件上工作，會出現一個彈出窗口，說'你不能在這個文件上工作，因爲USER A正在處理它'。

公司我工作來實現與Microsoft SQL Server兼容希望改變是微乎其微：所以我需要實現這樣的鎖定機制。我已經破解了一個在最小測試項目上工作的東西，但我不確定它是否符合行業和MSSQL的標準......

來源

2017-07-16 Maxime Bonin

我希望用戶永遠不要去吃午餐:-)。 –

你的意思是*記錄鎖*？這是一個RDBMS鎖實際上還是某種*自我管理*鎖標誌？ – Shnugo

@Shnugo：它不僅僅是一個標誌：應用了一個實際的RDBMS鎖。我們的代碼（使用Advantage Database Server的函數）對數據庫中的記錄應用鎖。我們的代碼在Delphi中，我們使用Advantage數據庫服務器中的模塊來應用鎖。在使用MSSQL數據庫（tru Delphi的FireDAC模塊）時不存在這樣的功能性 –

這是有點長的評論。

對此應用程序級鎖定使用數據庫鎖定機制似乎很不尋常。數據庫鎖可能位於行，頁面或表級別，並且還會影響索引，因此可能會出現意想不到的副作用。顯然，鎖的擴散也使得死鎖更可能發生。

通常，應用程序鎖定將在記錄級別上處理。在記錄中使用標記（某種）時，應用程序將確保只有一行可以訪問文件。

我會說，它可能工作。但我絕不會這樣設計一個系統，我會對意想不到的後果保持警惕。

來源

2017-07-16 16:39:26

同意！數據庫鎖定用於處理ACID合規性（對於初學者）而不是應用程序級別邏輯。內存數據結構可能？ – Namphibian

在現代數據庫系統中長時間保持記錄的常見做法？

回答

相關問題