Hibernate 数据库与多个 java 应用程序的完整性
我们有 2 个 Java Web 应用程序,都是读/写应用程序,还有 3 个独立的 Java 读/写应用程序(一个通过电子邮件加载问题,一个处理 xml feed,一个向订阅者发送电子邮件),所有应用程序都使用 hibernate 并共享通用代码库。
我们最近遇到的问题是,通过电子邮件加载的问题有时会覆盖在其中一个网络应用程序中创建的问题。请注意,这些是单独的问题,应该有单独的 ID。我们最初认为这是一个缓存问题。我们尝试过关闭二级缓存,但这并没有什么区别。
<property name="hibernate.transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.cache.use_second_level_cache">false</property>
问:
@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
@DocumentId
public Integer getId() {
return this.id;
}
顺便说一句,我们正在使用 MySQL。
CREATE TABLE `question` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
...
PRIMARY KEY (`id`),
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8
我们没有显式地打开和关闭会话,而是让 hibernate 通过 Util.getSessionFactory().getCurrentSession() 来管理它们。
我们不想在这个阶段设置集群二级缓存,因为这会增加另一层复杂性,而且我们对从应用程序整体获得的性能水平非常满意。
那么,在 Web 应用程序中实现开放会话视图模式并手动管理独立应用程序中的会话听起来是否可以解决此问题?
或者还有其他建议/想法吗?
We have 2 java web apps both are read/write and 3 standalone java read/write applications (one loads questions via email, one processes an xml feed, one sends email to subscribers) all use hibernate and share a common code base.
The problem we have recently come across is that questions loaded via email sometimes overwrite questions created in one of the web apps. Note, these are separate questions which should have separate id's. We originally thought this to be a caching issue. We've tried turning off the second level cache, but this doesn't make a difference.
<property name="hibernate.transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.cache.use_second_level_cache">false</property>
Question:
@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
@DocumentId
public Integer getId() {
return this.id;
}
We're using MySQL btw.
CREATE TABLE `question` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
...
PRIMARY KEY (`id`),
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8
We are not explicitly opening and closing sessions, but rather let hibernate manage them via Util.getSessionFactory().getCurrentSession()
.
We'd rather not setup a clustered 2nd level cache at this stage as this creates another layer of complexity and we're more than happy with the level of performance we get from the app as a whole.
So does implementing a open-session-in-view pattern in the web apps and manually managing the sessions in the standalone apps sound like it would fix this?
Or any other suggestions/ideas please?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
由于所有问题都有 id,所以我假设所有问题都是从您的 MySql 数据库中获取的。
假设您不需要将问题作为透明对象存储在内存中,而是在每次提出问题时选择所有问题,我有一个简单的建议。
将 ID 生成器替换为数据库中的序列。 (最终 ID 作为 MySql 中的自动编号)。然后数据库而不是应用程序保证每个问题都有一个唯一的 ID。
该解决方案非常简单,并且降低了复杂性。只有当您将来自不同来源的所有传入问题保存到数据库中,然后从此处选择它们时,它才有效。
如果此解决方案给您带来性能问题,您应该更多地研究 Hibernate id 生成器的工作原理。 Hibernate 为不同的场景提供了几种不同的生成器。
希望这有帮助!
Since all the questions have ids, then I assume that all questions are fetched from your MySql database.
Assuming that you don't need to store the questions as transparent objects in memory, but that you select all the questions for each time you present them, I have one simple suggestion.
Replace the ID generator with a sequence in the database. (Eventually the ID as autonumber in MySql). Then the database instead of the applications guarantees that every question gets a unique id.
This solution is quite simple and reduces your complexity. And it only works if you persist all incoming questions from the different sources into your database and then select them from here.
If this solution gives you performance problems, you should investigate more about how your Hibernate id generator work. Hibernate provides several different generators for different scenarios.
Hope this help!
事实证明这个问题与 Hibernate 根本无关。
登台服务器上的数据库表之一填满了本应清理的旧数据。这最初看起来像是 id 被覆盖,但进一步的调查证明并非如此!
一旦我们删除了可疑数据,一切就都好了。
Turns out this problem wasn't related to Hibernate at all.
One of the database tables on the staging server was filled with old data that should have been cleaned up. This initially gave the appearance of id's being overwritten, but further investigation proved otherwise!
Once we removed the dodgy data, all was well.