c# - Esent 和 Ravendb 中的 .Net 终结器顺序/语义

Question

帮助我理解。我读过

“终结器的执行时间和顺序无法预测或预先确定”

正确吗？

但是查看 RavenDB 源代码 TransactionStorage.cs 我看到了这个

~TransactionalStorage()
{
try
{
 Trace.WriteLine(
  "Disposing esent resources from finalizer! You should call TransactionalStorage.Dispose() instead!");
 Api.JetTerm2(instance, TermGrbit.Abrupt);
}
catch (Exception exception)
{
  try
  {
   Trace.WriteLine("Failed to dispose esent instance from finalizer because: " + exception);
   }
   catch
   {
   }
 }
}

API 类(属于 Managed Esent)可能使用 SafeHandle 处理 native 资源？

因此，如果我理解正确的话， native 句柄 SafeHandle 可以在 TransactionStorage 之前完成，这可能会产生不良影响，也许为什么 Ayende 为此添加了一个 catch all 子句？

实际上深入 Esent 代码，它不使用 SafeHandles。

根据 C# 的 CLR，这很危险？

    internal static class SomeType {  
   [DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")]  

 // This prototype is not robust  
   private static extern IntPtr CreateEventBad( 
      IntPtr pSecurityAttributes, Boolean manualReset, Boolean initialState, String name);  


 // This prototype is robust  
  [DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")]  
  private static extern SafeWaitHandle CreateEventGood( 
     IntPtr pSecurityAttributes, Boolean manualReset, Boolean initialState, String name)

  public static void SomeMethod() {  
     IntPtr         handle = CreateEventBad(IntPtr.Zero, false, false, null);  
     SafeWaitHandle swh    = CreateEventGood(IntPtr.Zero, false, false, null);  
  }  
}

Managed Esent (NativeMEthods.cs) 看起来像这样(使用 Ints 还是 IntPtrs？):

  [DllImport(EsentDll, CharSet = EsentCharSet, ExactSpelling = true)]
    public static extern int JetCreateDatabase(IntPtr sesid, string szFilename, string szConnect, out uint dbid, uint grbit);

Managed Esent 处理终结/处置的方式是否正确，其次 RavenDB 是否以正确的方式处理终结器或补偿 Managed Esent？

Answer 1

将 SafeHandles 与 ESENT 资源一起使用非常复杂且危险，因此我决定不这样做。主要有两个问题:

1. 与 Win32 句柄不同，ESENT 句柄是相互关联的，因此关闭一个句柄将隐式关闭其他句柄。
2. 关闭已经关闭的 ESENT 句柄是不安全的。

对于第一点，有几种情况需要考虑:

• JetRollback 将关闭事务内打开的所有表，但 JetCommit 不会。
• JetEndSession 将关闭 session 打开的所有表和数据库。
• JetTerm 可以关闭实例打开的所有 session 、表和数据库。

现在 JET_SESID 或 JET_TABLEID 实际上是指向内部结构的指针(我们尝试通过句柄表进行间接访问，但发现速度太慢，尤其是在被多线程使用时)。这意味着一旦资源关闭，内存就可以重新使用。再次释放资源可能会释放另一个线程的资源；就像双重释放指针一样。

这使得这段代码在最终确定时非常具有挑战性:

void Foo(JET_SESID sesid, JET_DBID dbid)
{
    JET_TABLEID tableid;

    Api.JetBeginTransaction(sesid);
    Api.JetOpenTable(sesid, dbid, "table", null, 0, OpenTableGrbit.None, out tableid);
    // do something...
    if (somethingFailed)
    {
        Api.JetRollback(sesid, RollbackTransactionGrbit.None);
    }
    else
    {
        Api.JetCommitTransaction(sesid, CommitTransactionGrbit.None);
    }
}

如果 JET_TABLEID 包装在 SafeHandle 中，我们必须知道 JetRollback() 调用(它甚至不将 tableid 作为参数)已经关闭了表，因此终结器无法关闭表。另一方面，如果我们采用提交路径，那么终结器应该关闭表。

如果 JET_SESID 也是一个 SafeHandle，那么我们必须跟踪执行终结器的顺序。如果 JET_SESID 已经完成，那么我们无法关闭 JET_TABLEID。

跟踪实例、 session 、表和事务之间的关系，然后在终结器中做正确的事情将非常困难，最好使用比 ManagedEsent 提供的更复杂的对象模型来完成。

但是，我们可以将 SafeHandle 与 JET_INSTANCE 一起使用，因为没有可以隐式关闭实例的 API。 Instance() 包装器就是这样做的。为什么不让 JET_INSTANCE 成为 SafeHandle？在某些情况下，应用程序想要在不终止 ESENT 的情况下退出——终止可能会很慢，而对于持久事务，如果你只是退出程序，你实际上不会丢失任何信息——数据库恢复将在 JetInit 自动运行。

就终结器顺序而言，我相信关键终结器(例如 SafeHandles)总是在所有正常终结器运行之后运行。