我們正在使用OODBMS，它同時允許Java「實體」和序列化對象。數據庫支持真正的圖形（無「樹」限制），序列化對象也可以安全地引用實體。 DB（幾乎）透明地工作，我們可以做任何我們想要的，而且它只是工作。序列化時可以找到「引用/父對象」嗎？
現在，我發現被標記爲「邏輯刪除」的對象（使用簡單的布爾標誌，而不是內置的DB功能，因爲DB沒有這樣的概念）被加載/保存在特定的對象圖中。
我想知道哪些對象引用了這些「殭屍」對象。嘗試使用反射來遍歷圖表目前還沒有工作。我可以簡單地使用Java序列化來導出對象圖，而不是數據庫，這也會導致「殭屍」對象被序列化。
我的問題是：我可以以某種方式提取關於在序列化過程中持有對「殭屍」對象的引用的對象的信息（「父對象」）嗎？可以有更多的，但只要我有一個，我可以迭代工作，直到我殺死所有這些無效的引用。
大多數OODBMS允許運行查詢，該查詢返回滿足某些約束條件的對象引用。所以，你可以寫這樣的事情：
return all objects
where deleted == true
and Foo.bar == this
其中Foo是引用刪除的對象和bar對象的類型是字段/屬性，它包含了參考。
確切的語法取決於您的OODBMS。
事實上，*大多數*做，但不是我們的（這是更不用說我們的產品的原因之一;我沒有試圖給他們做壞的宣傳），所以這不是我們的解決方案。此外，它僅適用於實體的「直接」引用，而不適用於隱藏在序列化對象中的引用。 –
在這種情況下，您需要遵循事情的方式或給我更多信息。注意：如果數據庫可以序列化一個引用，那麼它不是「隱藏」的。如果它可以序列化引用，那麼它也可以以某種方式查詢它。沒有這個，數據庫甚至無法加載兒童。 –
簡而言之，DB服務器是運行查詢的服務器，但對於服務器，序列化對象只是字節數組。序列化對象的實際（反序列化）發生在客戶端上，這意味着可能需要許多服務器調用來完全加載大對象圖，但這對我們來說都是透明的。這也意味着服務器不知道這些字節數組內的實體的引用。數據庫爲實體（64位長）使用統一的ID空間，並在序列化期間將實體引用替換爲「句柄」。我們不能修改Handle類。 –
您使用哪種OODBMS？哪個版本？ –
我們引入「邏輯刪除」標誌的原因是因爲數據庫沒有提供查找「父」對象的方法，因此也沒有爲實體提供「GC」。長期目標是驗證標記爲邏輯刪除的所有對象都是真正未引用的，所以我們最終可以刪除它們。 –