从 JNDI 连接池检索的数据库连接设置
我在 Websphere 服务器上托管了一个数据源，并且希望通过我的应用程序客户端使用该数据源。
从 JNDI 数据源检索数据库连接后，我将连接的提交设置更改为 false。之后，我将使用这个连接，并在任务完成后关闭该连接。
如果我在关闭之前忘记更改连接的提交设置（我的意思是将连接返回到池中），会发生什么情况。如果任何其他客户端访问此数据源并且它们获得相同的连接，则提交设置是否仍然保留，或者服务器是否会重置这些连接设置。
I have hosted a data source on the Websphere server and I wanted make use of that data source through my application clients.
After retrieving the database connection from the JNDI data source, I am changing the commit setting of the connection to false. After that, I will make use of this connection and I will close the connection after the completion of the task.
What happens if I forget to change the commit setting of the connection before closing (I mean returning the connection to the pool). If any other client accesses this data source and they get the same connection, does the commit settings still persists or will the server reset these settings of the connections.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，池中的连接是用 AS 特定的实现来包装的，这可以解决客户端的过度侵入问题。当在连接上调用特定方法时，它被认为是“脏”的，并且可能不会返回到池中，而是关闭并重新创建，或者如果可能的话重置为原始状态。通常有关于如何处理这些情况的设置，例如 Weblogic 中的删除受感染的连接。
不过，这些自清洁的效果也可能取决于驾驶员。因此我建议你用1个连接池做一个简单的测试。将连接设置为 autocommit=false，不要关闭它，退出并尝试从另一个客户端使用它，并通过测试检查 autocommit 属性的实际状态。
另一件需要考虑的事情是 AS 包装器中的 Connection.close() 不会关闭连接，而是将其放入池中。因此，如果您的客户端在调用 close() 之前断开连接（并在此之前设置自动提交），则该连接可能对其他池客户端不可用，从而造成连接泄漏。
Normally connections in the pool are wrapped with a AS-specific implementation, which takes care of the client being too intrusive. When specific methods are called on the connection, it is considered "dirty", and may not be returned to pool, but closed and recreated instead, or reset to original state, if possible. There are often settings on how to deal with those situations, e.g. Remove Infected Connections in Weblogic.
The effect of those self-cleansing though could depend on the driver as well. Therefore I suggest you do a simple test with a 1-connection pool. Set connection to autocommit=false, do not close it, exit and try to use it from another client with a test checking the actual state of autocommit property.
Another thing to consider is that Connection.close() in that AS wrapper doesn't close the connection, but places it into the pool. Therefore if you client disconnects before calling close() (and setting autocommit back right before that), the connection may be not available to other pool clients, creating a connection leak.
在 Apache Tomcat + Postgres 上测试 - if;未指定 - 返回的数据库连接保持修改状态，也就是说，您必须在关闭（返回）之前手动设置它
defaultAutoCommitat server.xmlconn.setAutoCommit(true);。但defaultAutoCommit="true"在这种情况下会有所帮助。 Apache Tomcat 7 - Tomcat JDBC 连接池 解释defaultAutoCommit- “（布尔值）此池创建的连接的默认自动提交状态。如果未设置，则默认为 JDBC 驱动程序默认状态（如果未设置，则不会调用 setAutoCommit 方法。）”Tested on Apache Tomcat + Postgres - if
defaultAutoCommitat server.xml <Resource ..../> is not specified - returned database connection remains modified, that is, you have to set it manuallyconn.setAutoCommit(true);before closing (returning). ButdefaultAutoCommit="true"helps in this situation. Apache Tomcat 7 - The Tomcat JDBC Connection Pool explainsdefaultAutoCommit- "(boolean) The default auto-commit state of connections created by this pool. If not set, default is JDBC driver default (If not set then the setAutoCommit method will not be called.)"