多谢多谢
我们现在的做法其实也差不多，是建立连接池，保持连接，有业务需要直接就用了。
不过空闲的连接在一段时间后会被我们的防火墙断开，所以为了保持连接池的连接状态，就打算发心跳保活。不过，心跳也有可能发出去就没反应了，这段时间我们希望可控，如果超时就做后续的自愈处理。
但是 oracle 自己的库貌似不支持我们这么做。
咱们的做法差不多相反，不过看起来比我们合理得多。我可以试试。
多谢指教
本帖最后由 yulihua49 于 2016-10-10 11:14 编辑
VIP_fuck 发表于 2016-10-09 16:00
回复 10# yulihua49
多谢多谢
那你的要抢在防火墙之前断掉。就是说t0必须小于防火墙断线时间。看来我的连接池的t0应该是可配置的。
但是正在使用的连接你是管不了的，这就要求使用者得到连接后，必须使用，不使用了就必须归还，静止时间必须小于防火墙的断线时间。
还有一个问题，求如果一个请求，数据库长时间不应答，防火墙是会断开的，这你怎么解决？完全
因此我建议数据库不跨防火墙。
外部的客户端不直接访问数据库，要通过交易服务器来访问数据库。客户端与交易服务器间有防火墙，交易服务器与数据库间直接联系。
这就是交易中间件的作用。
本帖最后由 yulihua49 于 2016-10-10 11:25 编辑
yulihua49 发表于 2016-10-10 11:00
那你的要抢在防火墙之前断掉。就是说t0必须小于防火墙断线时间。看来我的连接池的t0应该是可配置的。
但 ...
交易中间件是协助开发在线交易系统(OLTP)的C/S/S应用框架。它提供如下功能：
[*]支持大量客户端的连接和高并发度的交易处理。帮助应用系统有效的使用服务器的各种资源，如CPU、内存、文件系统、数据库、IO设备等等，方便的实现并发操作，包括一个主机各种资源的并发使用和多台服务器主机的资源的并发使用。
[*]方便的定制应用服务功能，实现服务器端的应用业务逻辑。一般是通过远过程调用实现。也可以这么说，应该能够自定义远过程。这也意味着，在C/S间提供半双工的信息通道，区别于消息中间件的单工通道。
[*]对各个层次的资源能够均衡的使用，如数据库，各服务器及各CPU，各IO系统等。
[*]应能提供一定程度的交易安全保证，以便系统能够在开放的网络环境下进行安全的交易。
[*]提供应用路由，即内容决定的路由。
[*]提供分布式交易完整性管理（两阶段提交） 一个交易框架系统，至少提供1，2才可以称为交易中间件。
商品的有TUXEDO，东方通等，价格不菲。开源的也有。SDBC算一个，SDBC 是Secure DataBaseConnect（安全数据库连接）的缩写。
回复 13# yulihua49
多谢，我们这个估计不会用中间件，防火墙也去不掉。
再想想别的办法吧。
occi 本身基本是指望不上了，或者我们会。。。绕过这个，用个比较笨的办法也说不准。
VIP_fuck 发表于 2016-10-10 11:28
回复 13# yulihua49
多谢，我们这个估计不会用中间件，防火墙也去不掉。
中间件你可以自己写，可以参照别人的经验。
回复 15# yulihua49
多谢指教 yulihua49 发表于 2016-09-26 16:48
数据库无需心跳。
我们不用心跳保活机制，因为谁也保不了活。
我们是自愈机制，就是谁有病，你管不了， ...
这个思路不错，好像很多公司都是这么干的 本帖最后由 yulihua49 于 2016-10-26 10:34 编辑
感冒九十九 发表于 2016-10-25 14:39
这个思路不错，好像很多公司都是这么干的
简单说来，就是“保死”。
既然谁也保不了活，那就都给他弄死。这样，状态就是确定的，肯定是死的。无需健康检查和健康维护。系统变得极其简单。
谁使用谁打开。经常用不关闭，这样保持高效率。发生异常或久不使用就关闭。
无论“保活”还是“保死”，都解决不了一个问题：数据库请求发出之后，长时间不回应，中间的防火墙关闭连接的问题。
这要从两个方面下手。
1.跨防火墙的数据库访问，没有长响应时间的访问，优化你的语句。
2.改变系统架构，使用中间件，数据库和中间件在一个域。中间件访问数据库不受限制。客户端与中间件间的访问受控，但是协议是你自己的，可以采用各种方法来解决。
页:
1
[2]