jdbc连接可以恢复吗?

发布于 2024-12-04 23:01:11 字数 371 浏览 1 评论 0原文

由于数据库不可用而关闭的 jdbc 连接是否可以恢复。

为了提供背景,我按顺序得到以下错误。看起来不是手动重启。我的问题的原因是我被告知该应用程序在没有 重新开始。因此,如果连接丢失,在数据库重新启动后可以恢复吗?

java.sql.SQLException: ORA-12537: TNS: 连接已关闭

java.sql.SQLRecoverableException: ORA-01034: ORACLE 不可用 ORA-27101: 共享内存领域不存在 IBM AIX RISC System/6000 错误:2:没有这样的文件或目录

java.sql.SQLRecoverableException:ORA-01033:ORACLE 初始化或关闭正在进行

Can jdbc connections which are closed due to database un-availability be recovered.

To give back ground I get following errors in sequence. It doesn't look to be manual re-start. The reason for my question is that I am told that the app behaved correctly without
the re-start. So if the connection was lost, can it be recovered, after a DB re-start.

java.sql.SQLException: ORA-12537: TNS:connection closed

java.sql.SQLRecoverableException: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
IBM AIX RISC System/6000 Error: 2: No such file or directory

java.sql.SQLRecoverableException: ORA-01033: ORACLE initialization or shutdown in progress

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

江湖彼岸 2024-12-11 23:01:11

不。连接已“断开”。创建一个新连接。

一个好的方法是使用 连接池,它将测试如果连接仍然正常,则在将其提供给您之前,并在需要时自动创建新连接。

有几个开源连接池可供使用。我使用过 Apache 的 JDCP,它对我有用。

已编辑:
鉴于您希望等到数据库在出现故障时恢复正常(有趣的想法),您可以实现 getConnection() 的自定义版本,如果数据库没有恢复,它会“等待一段时间并重试”不回应。

ps我喜欢这个主意!

No. The connection is "dead". Create a new connection.

A good approach is to use a connection pool, which will test if the connection is still OK before giving it to you, and automatically create a new connection if needed.

There are several open source connection pools to use. I've used Apache's JDCP, and it worked for me.

Edited:
Given that you want to wait until the database comes back up if it's down (interesting idea), you could implement a custom version of getConnection() that "waits a while and tries again" if the database doesn't respond.

p.s. I like this idea!

泡沫很甜 2024-12-11 23:01:11

连接无法恢复。可以做的是将连接故障转移到另一个数据库实例。 RAC 和 Data Guard 安装支持此配置。

这对于只读事务来说没有问题。然而,对于执行 DML 的事务来说,这可能是一个问题,特别是如果最后一次调用数据库是提交的话。在提交的情况下,客户端无法判断提交调用是否完成。数据库什么时候出现故障;在执行提交之前,或执行提交之后(但不向客户端发送回确认)。只有应用程序有这个逻辑并且可以做正确的事情。如果故障转移后的应用程序不验证最后事务的状态,则可能会出现重复事务。这是一个众所周知的问题,我们大多数人在购买门票或类似的网络交易时都遇到过这个问题。

The connection cannot be recovered. What can be done is to failover the connection to another database instance. RAC and data guard installations support this configuration.

This is no problem for read-only transactions. However for transactions that execute DML this can be a problem, especially if the last call to the DB was a commit. In case of a commit the client cannot tell if the commit call completed or not. When did the DB fail; before executing the commit, or after executing the commit (but not sending back the acknowledgment to the client). Only the application has this logic and can do the right thing. If the application after failing over does not verify the state of the last transaction, duplicate transactions are possible. This is a known problem and most of us experienced it buying tickets or similar web transactions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文