当应用程序池回收或工作进程被强制终止时，事务会发生什么？
应用程序的架构非常简单。有一个网络应用程序可以维护帐户持有者数据。根据业务规则的数量处理这些数据并更新帐户持有人的状态。此过程是使用页面上的按钮启动的，并且是一个长时间运行的过程（例如 15 分钟）。开发了一个组件来执行此数据处理，该组件在内部调用存储过程。大多数业务规则都保存在存储过程中。
为了处理超时，处理是异步完成的（使用线程池或自定义线程或异步回调委托）。整个流程在事务下运行。我想知道您对应用程序池被回收或工作进程被强制终止时事务会发生什么情况的看法？
The architecture of the application is straight forward. There is a web application which maintain account holder data. This data is processed and the status of account holders is updated based on number of business rules. This process is initiated using a button on the page and is a long running process (say 15 mins). A component is developed to do this data processing which internally calls stored procedures. Most of the business rules are kept in stored procedure.
To handle timeouts the processing is done asynchornously(using Thread Pool or custom thread or Async Callback Delegates). The entire process run under a transaction. I would like to know your view on what happens to the transaction if the app pool is recycled or the worker process is terminated forcefully?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我假设您使用的是 SQL 数据库，例如 SQL Server、MySQL 或 Oracle。
这些数据库平台有自己的内部事务模型。当您与他们通信并发起交易时，服务器会为您管理交易。
对于要提交的事务，客户端必须告诉数据库提交更改。如果交易从未收到此指令，则交易将保持“待处理”状态。最终，在事务处于“待处理”状态且没有任何进一步指示的情况下，服务器将认为它“已死亡”并放弃它，对事务执行回滚。
这是事务处理的最坏情况，因为挂起的事务可能（取决于隔离级别）导致数据库中的资源（行、页、整个表）不可用。通常，当网络连接在事务中失败（例如由于断电）并且客户端未向服务器发送“关闭连接”命令时，您会看到这种情况。
如果您的应用程序在事务期间处理数据库时通过回收应用程序池而终止，与数据库的连接将被关闭。关闭连接的这一行为应导致服务器放弃与该连接关联的任何待处理事务。
确切的行为将取决于特定的数据库和配置。
无论哪种情况，您的数据库数据都将保持不变。
I'm going to assume you're using a SQL database like SQL Server, MySQL or Oracle.
These database platforms have their own internal transactional model. When you communicate with them and initiate a transaction, the server manages the transaction for you.
For a transaction to commit, the database has to be told by the client to commit the changes. If the transaction never receives this instruction, the transaction remains in a "pending" state. Eventually, after the transaction is "pending" without any further instructions, the server will consider it "dead" and will abandon it, perform a rollback on the transaction.
This is the worst-case scenario for transaction-handling, as a pending transaction may (depending on isolation level) cause resources in the database (rows, pages, entire tables) to be unavailable. Normally you see this when a network connection has failed mid-transaction (e.g. from power loss) and the client does not send the "close connection" command to the server.
If your application is terminated by having the Application Pool recycled whilst in the middle of working against the database during a transaction, the connection to the database will be closed. This act of closing the connection should cause the server to abandon any pending transactions associated with the connection.
The exact behaviour will depend on the specific database and configuration.
In either case, your database's data will remain intact.
如果工作进程终止，我认为应用程序会回滚。
但你必须测试。
If the worker process is terminated, I think application rollbacks.
But you have to test.