Transaction Finalizers — Overview & APIs

同学们，今天我们来聊一个比较实用的话题——事务终结器，也就是Transaction Finalizers。听不懂没关系，我们把它拆开揉碎了讲。 先想象一下，你安排了一个定时任务，比如每晚自动给客户发邮件。万一这个任务执行失败了怎么办？你肯定希望它能自动重试几次，而不是一次失败就彻底罢工。事务终结器就是用来处理这种“失败重试”的帮手。 它怎么工作呢？用System.Finalizer这个接口，你可以把一段处理逻辑“附”在你的可安排作业上。当你的作业运行结束，不管是成功还是失败，系统会自动调用这段逻辑。重点是：如果失败了，这个终结器可以帮你把作业重新塞回队列里，而且最多能重复排队5次，超过5次就放弃了，防止无限循环。 每次执行这个终结器时，它会给你一个上下文对象，你可以通过它拿到一些关键信息：作业的ID、这次运行的请求ID、最终结果（要么是SUCCESS，要么是UNHANDLED_EXCEPTION），以及如果异常了，详细的异常信息。这样你就可以在日志里精准记录，或者根据不同的失败原因做不同的处理。 有一个要注意的规则：一个作业只能挂一个终结器，不能绑多个。而且，你原来的作业主体和这个终结器是在两个独立的事务中运行的。这是什么意思呢？就是说作业本身做的数据修改，可能在终结器运行时还没提交，或者已经回滚了，所以终结器里不要依赖作业中途的状态。 好消息是，调用终结器不算在你的每日异步执行次数配额里，不用担心它吃掉你的限额，你可以放心使用。 那代码里怎么写呢？很简单，在你的execute方法里，用System.attachFinalizer(yourFinalizer)把它附加上去就行了。终结器一般实现为一个实现了System.Finalizer接口的内部类或外部类。 最后给开发同学提个醒：如果你在托管包中写了一个全局的终结器类，而且里面有会修改自身状态的方法（比如计数），一定要特别小心。因为在升级包或不同版本共享时，这些可变状态可能引发意想不到的行为。尽量把终结器做得纯粹、无副作用，只做重试和日志记录，别在里面搞复杂的业务逻辑。 简单总结一下：事务终结器就是可安排作业的“急救员”，帮你自动重试失败任务，提供详细信息，不占配额，但每个作业只能有一个，且运行在单独事务中。它通过System.attachFinalizer()挂载，托管包里避免可变状态。 好，这一节就到这里。有什么问题，随时问。