tomcat 重新部署时的 JDBC 事务行为 [英] JDBC Transactions behaviour while tomcat redeploying

问题描述

当我有许多活动的 JDBC 事务并且重新部署命中 Web 应用程序时会发生什么?，我搜索了 Tomcat 文档但没有找到任何相关内容.

What happens when I have a number of active JDBC transactions and a redeploy hits the web application?, I searched the Tomcat docs but didn't find anything related.

例如:30个客户有一个购物车，他们同时保存了订单，因此开始交易，并触发重新部署发生什么了?是否所有项目都得到正确保存?或者在重新部署时所有活动事务都被丢弃?或者 Tomcat 等待重新部署命令，直到所有事务都提交?

For example: 30 customers have a shopping cart with items and they save the order at the same time, so a transaction is started, and a redeploy is triggered What happens? Do the all items get correctly saved? or At time of redeploy all active transactions are discarded? or Tomcat waits the redeploy command till all the transactions are commited?

我正在使用 Tomcat JDBC 池

I'm using Tomcat JDBC Pool

推荐答案

要记住的重点是连接池在哪里实例化?

The key point to keep in mind is where is the connection pool instantiated?

如果你在Context层定义了连接池，那么连接池在创建上下文的时候就被创建了，并且应该和上下文一起销毁.

If you define the connection pool at the Context level, then the connection pool is created when the context is created, and should be destroyed with the context too.

在 Tomcat 中重新部署应用程序需要关闭当前上下文，然后启动替换上下文.因此，在这种情况下，我希望行为将由 defaultAutCommit 或每个事务的autoCommit 的有效值.如果 true 然后关闭资源应该提交事务.如果 false 那么，就像任何 InterruptedException 一样，您的异常处理路径应该触发回滚，或者最坏的情况是连接关闭应该回滚事务.

Redeploying an application in Tomcat requires shutting down the current context and then starting up the replacement context. So in that case I would expect that the behaviour will be determined by the value of defaultAutCommit or the effective value of autoCommit for each transaction. If true then shutting down the resource should commit the transactions. If false then, just like with any InterruptedException your exception handling path should trigger rollback, or worst case the connection shutdown should rollback the transaction.

您真正想检查的是 Tomcat 如何关闭应用程序.我没有详细查看实际代码，但我的理解是它首先停止向旧上下文"发送请求.然后，一旦所有待处理的响应完成， ServletContextListeners 就会被调用以通知关闭，一旦它们和它们的 Filter 和 Servlet 对应物完成，上下文就会被有效地关闭，并且可以清理资源.更复杂的是，IIRC 是 Tomcat 不会等待响应完成，并且可能会开始中断处理程序，或者只是简单地切换到新的上下文而不等待旧的或完成拆卸.

What you really want to examine is how Tomcat shuts down an application. I have not looked at the actual code in detail, but my understanding is that first it stops sending requests to the "old context". Then once all the pending responses have completed, the ServletContextListeners get called to notify of shutdown, once they and their Filter and Servlet counterparts are completed, the context is effectively shut down and the resources can be cleaned up. What complicates things, IIRC is that Tomcat does not wait for ever for responses to complete and may start interrupting the handler treads, or just plain switch over to the new context without waiting for the old or to finish tearring down.

我不记得哪个容器(jetty/tomcat)支持启动新上下文，然后只有在新上下文准备好零停机切换时才切换请求处理......关键问题是你需要一个持久会话存储和可以在集群上安全运行的应用程序，以便能够使用这种部署模式.

I annot remember which container (jetty/tomcat) supports starting up the new context and then switching request handling over only once the new context is ready to give zero downtime switch over... The key issue with that is you need a persistent session store and an applcation that can run on a cluster safely to be able to use such a deployment mode.

简而言之，您的应用程序将在新上下文开始之前正常关闭，因此我希望事务完成或制定 InterruptedException，此时您的 try...finally 块应该启动

In short, your applcation will be shutdown gracefully before the new context starts, so I would expect transactions to either complete or recipe an InterruptedException at which point your try...finally blocks should kick in

这篇关于tomcat 重新部署时的 JDBC 事务行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！