【问题标题】:what are the preferred ways to persist data in server in runtime在运行时将数据持久保存在服务器中的首选方法是什么
【发布时间】:2013-05-06 21:08:30
【问题描述】:

我有一个 Web 应用程序,它的 UI 由 Struts Action 类处理其请求。

假设 UI 在一次请求中发送 30 个变量的数据。动作类处理请求并将 30 个变量存储在一个 java 对象中。

我需要持久化超出请求范围的数据(即使在服务器将收到的请求的响应发送回客户端后,数据也必须持久化),因为我有另一个依赖于这个持久化数据的 servlet(那些 30通过 UI 更新的变量)。

坚持的方法:

  1. 将其存储在数据库中
  2. 使用 JPA
  3. 使用静态变量。
  4. 使用 MQ

以上你更喜欢哪一个?我猜第三个选项不成立。

为更清晰添加点:

  • UI 发送请求(包含大约 30 个字符串变量数据) 每 1 分钟。对于每一分钟,持久化的数据必须是 修改。

  • 另一个依赖此持久数据的 servlet 是不可能的
    与请求有关,因此我相信会话上下文不会 共享。

【问题讨论】:

  • 不要使用静态变量
  • 了解数据的存储位置取决于您的要求。您甚至可以在请求属性中传递所有数据,无需数据库交互或 HTTP 会话(ab)使用。
  • @LuiggiMendoza 出于好奇,HTTP 会话的缺点是什么?
  • 我忘了补充几点,请参考最后一段编辑的内容
  • @austin 这很好解释here

标签: java performance memory jpa static-members


【解决方案1】:

你能用HttpSession吗?您可以将数据放在会话中,将其存储在服务器端,然后在请求之间持久化并可供其他 servlet 使用。

【讨论】:

  • 你是在用另一个问题回答一个问题吗?
  • 不是 4 个选项之一,所以我想也许已经考虑过了。
  • @anakata 我问了一个问题,这个问题可能是一个答案,而不是一个问题的问题。我同意你的看法,滥用 HttpSession 是个坏主意。不过,提供解决方案取决于非功能性需求。
  • 谢谢,如前所述,我已经考虑过会话选项,但它不起作用。
【解决方案2】:

信息不足。这实际上取决于您尚未详细说明的许多不同因素(应用程序的功能、数据量等)。在特定情况下,所有这些方法都可能是正确的方法。在某些奇怪的情况下,即使是静态变量选项也可能是正确的。

【讨论】:

  • +1 当然!,比如当你需要在不同的客户端之间共享相同的数据时,你可以考虑静态变量,那么我又觉得数据库更安全。
  • 静态变量从来都不是多线程环境下的最佳解决方案。
  • 一个非常同步的单例......我知道这是一种反模式......但有时它会起作用
猜你喜欢
  • 1970-01-01
  • 2013-04-27
  • 1970-01-01
  • 1970-01-01
  • 2020-05-17
  • 1970-01-01
  • 2015-12-11
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多