2

我正在尝试将一组简单的插入操作发送到 Azure 表存储，但似乎整个批处理事务已失效，并且使用托管的 azure 存储客户端，如果在批次到预先存在的记录。（使用 2.0 客户端）：

public class SampleEntity : TableEntity
{
    public SampleEntity(string partKey, string rowKey)
    {
        this.PartitionKey = partKey;
        this.RowKey = rowKey;
    }
}


var acct = CloudStorageAccount.DevelopmentStorageAccount;
var client = acct.CreateCloudTableClient();
var table = client.GetTableReference("SampleEntities");

var foo = new SampleEntity("partition1", "preexistingKey");
var bar = new SampleEntity("partition1", "newKey");

var batchOp = new TableBatchOperation();
batchOp.Add(TableOperation.Insert(foo));
batchOp.Add(TableOperation.Insert(bar));

var result = table.ExecuteBatch(batchOp);  // throws exception: "0:The specified entity already exists."

使用 InsertOrMerge 可以避免批处理级异常，但随后每个单独的操作响应都会返回 204，无论该特定操作是否插入或合并它。因此，客户端应用程序似乎不可能保留它或集群中的另一个节点是否插入了记录的知识。不幸的是，在我目前的情况下，这些知识对于某些下游同步是必要的。

是否有一些配置或技术允许批量插入继续并返回每个项目的特定响应代码而不会引发一揽子异常？

4

1 回答 1

1

如您所知，由于批处理是一种事务操作，因此您将获得一种全有或全无的交易。批处理事务有趣的一件事是您获得批处理中第一个失败实体的索引。因此，假设您尝试在批处理中插入 100 个实体，并且表中已经存在第 50 个实体，批处理操作将为您提供失败实体的索引（在本例中为 49）。

是否有一些配置或技术允许批量插入继续并返回每个项目的特定响应代码而不会引发一揽子异常？

我不这么认为。一旦第一个实体失败，交易就会失败。它甚至不会尝试处理其他实体。

可能的解决方案（只是大声思考:)）

如果我理解正确，您的关键要求是确定是否插入或合并（或替换）实体。为此，方法是从批次中分离出失败的实体并分别处理它们。基于此，我可以想到两种方法：

  1. 在这种情况下，您可能会将该批次分成 3 个批次：第 1 批次将包含 49 个实体，第 2 批次将仅包含 1 个实体（失败），第 3 批次将包含 50 个实体。您现在可以在第一批中插入所有实体，决定要对失败的实体做什么，然后尝试插入第三批。您需要一遍又一遍地重复该过程，直到此操作完成。
  2. 另一个想法是从批次中删除失败的实体并重试该批次。因此，在上面的示例中，在您的第一次尝试中，您将尝试 100 个实体，在您的第二次尝试中，您将尝试使用 99 个实体，依此类推，一直跟踪失败的实体（说明原因他们失败了）。批处理操作成功完成后，您可以处理所有失败的实体。
于 2013-05-29T11:51:05.317 回答