2010-05-12 81 views
4

我们有2个Java Web应用程序都是读/写和3个独立的Java读/写应用程序(一个通过电子邮件加载问题,一个处理XML订阅源,一个向订阅者发送电子邮件)休眠并共享一个通用的代码库。Hibernate数据库完整性与多个Java应用程序

我们最近遇到的问题是,通过电子邮件加载的问题有时会覆盖在其中一个Web应用程序中创建的问题。请注意,这些是单独的问题,应该有单独的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 BTW。

CREATE TABLE `question` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    ... 
    PRIMARY KEY (`id`), 
    ... 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 

我们没有明确开幕和闭幕会议,而是让Hibernate通过Util.getSessionFactory().getCurrentSession()管理。

我们宁愿不在现阶段设置集群二级缓存,因为这会造成另一层复杂性,我们对于从应用程序整体获得的性能级别感到满意。

那么,在Web应用程序中实现一个开放会话视图模式,并手动管理独立应用程序中的会话听起来就像它会解决这个问题?

或其他任何建议/想法请吗?

+0

如何确定问题(还有什么是主键)是同一个问题的邮件和网页更新? – Mark 2010-05-12 08:36:12

+0

听起来像主键是由应用程序生成的,而不是使用由数据库处理的序列。 – khmarbaise 2010-05-12 08:38:52

+0

嗨,刚刚更新我的问题与更多的信息给你。我认为IDENTITY策略导致id由MySQL生成? – Austen 2010-05-12 08:50:43

回答

0

原来这个问题根本与Hibernate没有关系。

登台服务器上的一个数据库表中充满了应该已清理的旧数据。这最初出现的id被覆盖,但进一步的调查证明,否则!

一旦我们删除了狡猾的数据,一切都很好。

3

由于所有问题都有ID,那么我假设所有问题都是从MySql数据库中提取的。

假设您不需要将问题存储为内存中的透明对象,但是每次提交时都选择所有问题,我有一个简单的建议。

用数据库中的序列替换ID生成器。 (最终将ID作为MySql中的自动编号)。然后,数据库而不是应用程序保证每个问题都得到一个唯一的ID。

该解决方案非常简单并且降低了复杂性。只有将所有来自不同来源的传入问题保留到数据库中,然后从这里选择它们,它才有效。

如果此解决方案给您带来性能问题,您应该调查更多关于您的Hibernate ID生成器的工作方式。 Hibernate为不同的场景提供了几种不同的生成器。

希望得到这个帮助!

+0

我已经为问题添加了我们的模式。那么你是否建议我们删除@GeneratedValue(strategy = IDENTITY)注释? – Austen 2010-05-12 09:37:10

+0

是的,我愿意。如果多个应用程序将值插入到同一个表中,则表上的插入触发器是最符合防弹要求的解决方案。这个触发器应该从一个序列中设置ID。 – Espen 2010-05-12 09:47:24

+0

如果我删除@GeneratedValue注释,我会得到:org.hibernate.id.IdentifierGenerationException:在调用save()之前,必须手动分配此类的ids: 您是否建议我手动计算数据库中的id direct,然后手动分配新问题? – Austen 2010-05-12 10:22:09