【问题标题】:MySQL time_zone 'current session' - is it IP or Connection?MySQL time_zone 'current session' - 是 IP 还是连接?
【发布时间】:2015-09-22 15:28:06
【问题描述】:

我有一个项目,间歇性地将 time_zone 值从用户定义的值更改为 SYSTEM,并且我正在尝试确定 MySQL 是否将“当前会话”(MySQL TimeZone) 视为连接,或者连接来自的工作站 IP。

基本上,如果不是每个连接,那么其他东西正在连接到 MySQL 并将 time_zone 值更改回 SYSTEM,这会对我已经连接的软件产生影响。

如果是每个连接,那么我会重新尝试找出 time_zone 被重置的位置。

更多信息,我的项目是用 Delphi XE3 编写的,使用 MyDAC 组件进行 DB 连接。当项目加载时,我读取一个连接文件,如果设置了 time_zone 字符串,我执行“Set Time_zone”查询。该连接在应用程序运行的整个生命周期内保持活动状态,并且对应用程序是全局的(即,我不创建/连接从该应用程序到数据库的其他连接)。

感谢您的帮助!

【问题讨论】:

  • 一个会话就是一个连接。
  • 您的会话是否长时间处于空闲状态?服务器可能会在超时后断开您的连接,并且 Delphi 库可能会自动重新连接。发生这种情况时,会话设置将丢失。

标签: mysql mydac


【解决方案1】:

一个 MySQL 会话对应一个连接。

MySQL 服务器在超时后自动断开空闲会话,基于系统变量wait_timeout 的值,默认为 28800 秒(8 小时)。听起来 Delphi 会自动重新连接您的会话,但是当这种情况发生时,每个会话的设置将会丢失。

您应该更改您的应用程序,以便在长时间空闲时发送时区设置。也可以增加wait_timeout(最大值为2147483,24.85天)。

【讨论】:

  • 谢谢,我就是这么想的,只是想在我陷入与我的问题无关的代码兔子洞之前澄清一下 - 我必须在 MyDAC 组件中添加一些东西检测重新连接并重新发送 time_zone 信息
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-09-22
  • 2012-01-16
  • 1970-01-01
  • 1970-01-01
  • 2012-11-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多