WebObjects/EOF/使用 EOF/併發
我們試圖修復一些我們一直在遇到的編輯上下文問題，並且我們正在考慮建立類似於以下架構的架構
首先注意... 我們有 WOAllowsConcurrentRequestHandling = true
- 建立一個 ThreadLocal 來延遲例項化一個 EOEditingContext，它有自己的新 EOObjectStoreCoordinator
- 當一個直接動作請求進來時，在 performActionNamed 中向 ThreadLocal 請求它的編輯上下文。
- 在 try 塊中鎖定 ThreadLocal 的編輯上下文。
- 處理請求並呼叫 generateResponse()。
- 在 finally 塊中解鎖 ThreadLocal 的編輯上下文。
- 返回響應。
所以我們最終會為每個工作執行緒獲得一個到資料庫的單獨連線。因此，我們可能會有很多到資料庫的連線。當工作執行緒完成時，我們將關閉到資料庫的連線。我們最終可能會使用 JavaPoolingJDBCAdaptor 來限制到資料庫的連線。但這將為我們應用程式提供良好的多執行緒併發訪問。
有人預見到這種方法有任何不良影響嗎？我在 WO 開發檔案中從未見過這種方法被提出。我的一位開發者建議了這種方法，我認為聽起來不錯，所以我想先看看其他人有什麼想法，然後再實施它。如果它執行良好，我們將很樂意分享我們的發現和程式碼。
我曾在以這種方式構建的應用程式上工作過，並且不滿意。只是讓你知道我的來歷 :-)
幾點想法
- 你將擁有多個快照 - 每個 EOObjectStoreCoordinators 都對應一個。它們不會同步。因此，您將失去樂觀鎖定，並且必須要麼實現某種跨堆疊通知，要麼透過頻繁獲取確保新資料（犧牲快取）。
- 您將使您的應用程式架構變得複雜，使其更難維護，更難理解，也更難交接給其他 WebObjects 開發人員。
- 您是否真的需要對所有查詢都進行多個併發連線到您的資料庫？我可以理解對配置檔案已確定為瓶頸的查詢這樣做。但是，如果可能的話，我可能會檢視其他最佳化（例如：將盡可能多的負載轉移到 SQL 伺服器）。
- 多個例項（儘管硬體成本更高）將更加乾淨，也更易於維護（即使*使用*實現更改通知架構）。
與往常一樣，這些意見僅代表我個人觀點，並歡迎討論 :-)
在鎖定方面，我認為這將沒問題。最有可能遇到的問題是記憶體使用。額外的 EOF 堆疊將比單個堆疊實現消耗更多記憶體。我假設這對於你的目的來說是可以的，即請求不會獲取很多資料。如果它們確實獲取了大量資料，或者你最終擁有許多工作執行緒，你可能會發現你的應用程式很快就會耗盡記憶體。您可能需要考慮對應用程式級別儲存的一組堆疊進行某種迴圈使用。這至少會在一定程度上限制記憶體使用。您也可能會因此在資料庫中遇到更多樂觀鎖定失敗。如果您正在執行多個例項（我記得這是這種情況），那麼您必須無論如何處理這些問題，因此這將不再是一個問題。