在线程中使用 TADOQuery

发布于 2024-10-17 05:55:43 字数 545 浏览 2 评论 0原文

我正在编写应用程序,它连接到数据库并重复(1 分钟间隔)从数据库读取数据。它类似于 RSS 提要阅读器,但具有本地数据库。如果数据读取失败,我会尝试重新建立连接。我设计它时将 TADOConnection 和 TADOQuery 放置在表单上(因此没有动态创建)。我的目标是从用户的角度保持应用程序“活跃”,因此我将连接和读取部分放入单个线程中。问题是,如何做到最好?

我的设计如下:

  • 创建
  • 应用程序启动时,TADOConnection和TADOQuery与表单打开连接一起在单独的线程(TADOConnection)中
  • ,如果连接建立,则挂起连接线程,启动表单上的计时器,该计时器定期恢复另一个线程用于数据读取
  • 如果读取线程成功,则没有任何反应并且表单计时器继续运行,如果失败,则线程停止计时器并恢复连接线程

动态创建 TADOConnection 或 TADOQuery 更好还是无关紧要?是否最好在线程中使用关键部分或其他东西(我同时只能对组件进行一次访问,并且只有一个线程)?

感谢您的建议

I'm writing the application, which connects to the DB and repetitively (1 minute interval) reads the data from a database. It's something like RSS feed reader, but with local DB. If the data reading fails, I try to reestablish the connection. I've designed it with TADOConnection and TADOQuery placed on the form (so with no dynamic creation). My aim is to keep the application "alive" from the user's point of view, so I placed the connection and the reading part into a single thread. The question is, how to do it best way ?

My design looks like this:

  • application start, the TADOConnection and TADOQuery are created along with the form
  • open connection in a separate thread (TADOConnection)
  • if the connection is established, suspend the connection thread, start the timer on the form, which periodically resumes another thread for data reading
  • if the reading thread succeeds, nothing happens and form timer keeps going, if it fails, the thread stops the timer and resume connection thread

Is it better to create TADOConnection or TADOQuery dynamically or it doesn't matter ? Is it better to use e.g. critical section in the threads or something (I have only one access to the component at the same time and only one thread) ?

Thanks for your suggestions

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

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

发布评论

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

评论(2

橘寄 2024-10-24 05:55:43

这个问题相当主观,可能还没有主观到足以结束,但无论如何都是主观的。这就是我选择动态创建 ADO 对象的原因:

  • 将所有内容放在一起:代码和用于访问代码的对象。使用在表单上创建的数据访问对象需要线程对表单的内部工作原理有深入的了解,这从来都不是一个好主意。
  • 它更安全,因为您无法从其他线程(包括主 VCL 线程)访问这些对象。当然,您不打算将这些连接用于其他用途,也不打算使用多线程等,但也许有一天您会忘记这些限制。
  • 它是面向未来的。您可能想使用其他项目中的同一线程。您可能想要添加第二个线程来访问同一个应用程序中的一些其他数据。
  • 我个人更喜欢从代码动态创建数据访问对象。是的,对主观问题的主观回答。

This question is fairly subjective, probably not subjective enough to get closed but subjective any way. Here's why I'd go for dynamically created ADO objects:

  • Keeps everything together: the code and the objects used to access the code. Using data access objects created on the form requires the Thread to have intimate knowledge of the Form's inner workings, that's never a good idea.
  • It's safer because you can't access those objects from other threads (including the main VCL thread). Sure, you're not planing on using those connections for anything else, you're not planning on using multiple threads etc, but maybe you'll some day forget about those restrictions.
  • It's future-proof. You might want to use that same thread from an other project. You might want to add an second thread accesing some other data to the same app.
  • I have a personal preference for creating data access objects dynamically from code. Yes, an subjective answer to a subjective question.
倦话 2024-10-24 05:55:43

运行线程中的所有内容。在线程中有一个周期性计时器,用于打开数据库连接,读取数据,将其“发布”回主线程,然后断开连接。线程在等待时间时需要“睡眠”,例如在 Windows 上,即使是由计时器发出信号的。 DB 组件是线程本地且私有的,可以在线程执行开始时(在应用程序启动时)在线程内部创建,并在线程执行完成时(在应用程序关闭时)释放。无论数据库连接是否暂时可用,这都将始终有效,并且主线程甚至不必与“数据库线程”进行通信。这是我一直使用的架构,而且绝对是防弹的。

Run everything in the thread. Have a periodic timer in the thread that opens the DB connection, reads the data, "posts" it back to the main thread, and then disconnects. The thread needs to "sleep" while waiting for the time, e.g. on a Windows even that is signalled by the timer. The DB components, which are local and private to the thread, can be created inside the thread when thread executions starts (on application startup), and freed when thread execution finishes (on application shutdown). This will always work, regardless of whether the DB conncetion is temporarily available or not, and the main thread does not even have to communicate with the "DB thread". It is an architcture that I use all the time and is absolulutely bullet-proof.

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