1

帮我理解。我读过

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

正确的？

但是查看 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
   {
   }
 }
}

假定使用 SafeHandle 处理本机资源的 API 类（属于 Managed Esent）？

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

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

根据 CLR 通过 C# 这很危险吗？

    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？

4

3 回答 3

7

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

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

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

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

现在 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。

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

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

至于终结器顺序，我相信关键终结器（例如 SafeHandles）总是在所有正常终结器运行后运行。

于 2010-05-21T18:12:30.210 回答
2

这里有很多问题。我的评论：

  1. 终结器必须假定终结器已经为所有其他类运行。例如，这将包括将Trace.WriteLine语句写入日志文件的类。
  2. catch 子句可能会或可能不会用于防止已经完成的类。通常终结器不会抛出异常，即使它们未能释放其非托管资源（因为这通常会使整个程序崩溃）。
  3. 托管 ESENT 当然应该使用SafeHandles，原因在此描述（即，在引发异步异常时防止泄漏，并防止句柄回收）。我真的很惊讶Laurion没有在这里使用最佳实践。
  4. ESENT 会话 ID 是IntPtrs，但它们的 DB ID 是uints。不过，它们都应该包装在一个SafeHandle派生类中。

简而言之，看起来这两个项目都没有处理完成或正确处理。正如我的第一篇 CodeProject 文章指出的那样，这是一个难题。

在托管 ESENT 发布之前，我已经开始为 ESENT API 开发自己的包装器，打算作为 OSS 发布。在与 Laurion 讨论了几次之后，我决定不这样做，因为微软也打算这样做。SafeHandle我拥有的代码功能不完整，但如果您有兴趣，它确实可以正确使用s。

另请注意，ESENT 在写入时没有向后兼容性（它将强制升级，因此在 Win7 上打开的 XP 数据库永远无法再被 XP 读取）。如果所有数据都在机器本地，这是一个不错的选择，但如果您需要将数据库复制到其他机器，则无法使用它。

于 2010-05-21T09:43:43.253 回答
1

我只是想澄清一些关于 SafeHandles 的事情。SafeHandles 不仅是 Finalizable 对象，它们还具有更强的终结保证，称为关键终结器，关键终结器保证在所有正常终结器都已经运行后运行。出于这个原因，您可以保证 SafeHandles 是最后完成的事情。

关键的最终确定是使 SafeHandle 安全的功能之一:)

此链接包含更多信息。希望这可以帮助。

于 2010-05-23T06:53:22.163 回答