hibernate正在选择中更新
【腾讯云】亏本大甩卖,服务器4核16G 1年370元(带宽12M,系统盘120GB SSD盘,月流量2000GB)!!!!!!
云产品 配置 价格
服务器 1核2G,带宽5M,系统盘50GB SSD盘,月流量500GB 38元/年
MySQL 1核1G 19元/年
服务器 16核32G,带宽18M,系统盘250GB SSD盘,月流量5000GB 1197元/年
点我进入腾讯云,查看更多详情

I have a legacy web app that I am maintaining. It started out as Java 1.4, but I've compiled it to Java5. We're using Spring+Hibernate. I'm not using annotations yet. I'm sticking with XDoclet for now. In it, I have an object graph that looks like this:

Job 1:m Operations 1:m Activities 1:m Transactions

Those Transactions are NOT J2EE transactions. We're just documenting the workflow from one Activity to another.

In HttpRequest#1, I update a couple of Activities and create a new Transaction. Then in HttpRequest#2, I redisplay the entire Job. What I am seeing at this point is the usual SELECT statements for the Job, Operations and Activities, but then I'm seeing some UPDATE statements for the Transactions. It turns out those updates are reverting the Transactions back to their previous states, discarding the latest updates.

Why in the world is Hibernate doing this?

As requested, here's the .hbm.xml file:

<hibernate-mapping>
  <class name="ActivityTransaction" table="imed_if_move_transactions"
    lazy="false" mutable="true">
    <cache usage="nonstrict-read-write" />
    <id name="id" column="IF_MOVE_TRANSACTION_ID" type="java.lang.Long">
      <generator class="sequence">
        <param name="sequence">IMED_IF_MOVE_TRANSACTIONS_S</param>
      </generator>
    </id>
    <property name="activityActionKey" type="java.lang.String"
      update="true" insert="true" column="ACTIVITY_ACTION_KEY" />
    <property name="approvalStatus" type="int" update="true"
      insert="true" column="APPROVAL_STATUS" />
    <property name="authorizedBy" type="java.lang.Long" update="true"
      insert="true" column="AUTHORIZATION_ID" />
    <many-to-one name="authorizedByUser"
      class="UserModel" cascade="none"
      outer-join="false" update="false" insert="false" not-found="ignore"
      fetch="select" column="AUTHORIZATION_ID" />
    <property name="date" type="java.util.Date" update="true"
      insert="true" column="JOA_TRANSACTION_DATE" />
    <many-to-one name="from"
      class="JobOpActivity" cascade="none"
      outer-join="false" update="true" insert="true" fetch="select"
      column="FM_JOB_OP_ACTIVITY_ID" />
    <property name="fromIntraActivityStepType" type="java.lang.Integer"
      update="true" insert="true" column="FM_INTRAACTIVITY_STEP_TYPE" />
    <property name="fromIntraOperationStepType" type="java.lang.Integer"
      update="true" insert="true" column="FM_INTRAOPERATION_STEP_TYPE" />
    <property name="fromOperationSeqNum" type="java.lang.Integer"
      update="true" insert="true" column="FM_OPERATION_SEQ_NUM" />
    <many-to-one name="job" class="Job"
      cascade="none" outer-join="false" update="true" insert="true" fetch="select"
      column="WIP_ENTITY_ID" />
    <property name="operationEndDate" type="java.util.Date"
      update="true" insert="true" column="OP_END_DATE" />
    <property name="operationStartDate" type="java.util.Date"
      update="true" insert="true" column="OP_START_DATE" />
    <many-to-one name="organization" class="Organization"
      cascade="none" outer-join="false" update="true" insert="true" fetch="select"
      column="ORGANIZATION_ID" />
    <property name="processingStatus" type="java.lang.String"
      update="true" insert="true" column="PROCESS_FLAG" />
    <property name="quantity" type="int" update="true" insert="true"
      column="TRANSACTION_QUANTITY" />
    <property name="reasonId" type="java.lang.Long" update="true"
      insert="true" column="REASON_ID" />
    <property name="reference" type="java.lang.String" update="true"
      insert="true" column="REFERENCE" />
    <property name="scrapAccountId" type="java.lang.Long" update="true"
      insert="true" column="SCRAP_ACCOUNT_ID" />
    <property name="spsaId" type="java.lang.Long" update="true"
      insert="true" column="SPSA_ID" />
    <many-to-one name="to"
      class="JobOpActivity" cascade="none"
      outer-join="false" update="true" insert="true" fetch="select"
      column="TO_JOB_OP_ACTIVITY_ID" />
    <property name="toIntraActivityStepType" type="java.lang.Integer"
      update="true" insert="true" column="TO_INTRAACTIVITY_STEP_TYPE" />
    <property name="toIntraOperationStepType" type="java.lang.Integer"
      update="true" insert="true" column="TO_INTRAOPERATION_STEP_TYPE" />
    <property name="toOperationSeqNum" type="java.lang.Integer"
      update="true" insert="true" column="TO_OPERATION_SEQ_NUM" />
    <property name="typeId" type="java.lang.Long" update="true"
      insert="true" column="TRANSACTION_TYPE_ID" />
    <property name="webKeyEntryId" type="java.lang.String"
      update="true" insert="true" column="WEB_KEY_ENTRY_ID" />
    <property name="issueMaterial" type="true_false" update="true"
      insert="true" column="MATERIAL_ISSUE" />
    <property name="createDate" type="java.util.Date" update="true"
      insert="true" column="CREATION_DATE" />
    <property name="createdBy" type="java.lang.Integer" update="true"
      insert="true" column="CREATED_BY" />
    <property name="lastUpdateDate" type="java.util.Date" update="true"
      insert="true" column="LAST_UPDATE_DATE" />
    <property name="lastUpdatedBy" type="java.lang.Integer"
      update="true" insert="true" column="LAST_UPDATED_BY" />
  </class>
</hibernate-mapping>

And here's an example transaction setup:

<bean id="moldingActivitiesService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
  <property name="transactionManager" ref="etrack2ProviderTransactionManager"/>
  <property name="target" ref="moldingActivitiesServiceTarget"/>
  <property name="transactionAttributes">
    <props>
      <prop key="*">PROPAGATION_REQUIRED</prop>
    </props>
  </property>
</bean>

#0

From some Hibernate Javadoc document on Google http://ajava.org/online/hibernate3api/org/hibernate/FlushMode.html:

AUTO

public static final FlushMode AUTO 

The Session is sometimes flushed before query execution in order to ensure that queries never return stale state. This is the default flush mode.

Every modification you are doing on a JPA-managed entity is done in a persistent context. That means Hibernate is assuming that the things that you modify in your entity are safe to be committed. So when you select data from the same entity or related entities, in this mode Hibernate puts consistency of your changes over everything else. So it flushes and then does the read to reflect your changes correctly. If you do not want to have this behavior you can do two things:

  • disable auto-commit (which I prefer, but it is some kind of a JPA convention, so make up your mind). The downside of this approach is that you have to do more by hand depending on your configuration. The upside is, that everything is much more explicit and less magic
  • change your code that you collect the data you need first. Also this would make your code much cleaner. Because it would work like the basic computer science pattern everybody understands: Input, Computation, Output. Your mixing those things up, which is the reason why the default mode does not work.

Edit: On how to use Spring's PlatformTransactionManager best without using annotations I would recommend the TransactionTemplate: http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/transaction.html#tx-prog-template Just inject your PlatformTransactionManager (Hibernate) there and use it to abstract from the transaction handling.

#1

Depending on your FLUSHMODE you will see this, because whenever you do a query, hibernate will normally guess as to whether it should FLUSH to get a clean and consistent read.

#2

Ok, finally found the problem. Here's a more complete flow:

I have Controller C1, Manager M1, Manager M2 and Persister P1. M1 and M2 have managed transactions as I stated above, using TransactionProxyFactoryBean.

  • C1.methodA() calls M1.methodB() which calls P1.methodC()
  • C1.methodA() then calls M2.methodD(), which then calls M1.methodE() which calls P1.methodF().

See the problem yet?

It happens when M1.methodD calls M1.methodE(). What I think happens is that since both M1 and M2 are transaction managed, two transactions are created, one for each call. Those two transactions battle it out for which one has the true state of the system, with neither one truly winning.

推荐文章

MS Access全文和文件搜索

MS Access全文和文件搜索

推荐文章

asp.net时区格式文化信息

asp.net时区格式文化信息

推荐文章

高负载下正常gc的jvm配置

高负载下正常gc的jvm配置

推荐文章

jqGrid-向每行添加编辑按钮

jqGrid-向每行添加编辑按钮

推荐文章

SQL查询随机花费很长时间

SQL查询随机花费很长时间

推荐文章

这个节目里有什么

这个节目里有什么

推荐文章

微调器与活动指示器

微调器与活动指示器

推荐文章

在C或VB.Net中是否合法?

在C或VB.Net中是否合法?

推荐文章

如何用独特的点击“另存为”?

如何用独特的点击“另存为”?

推荐文章

如何获取区域设置的iso2语言代码?

如何获取区域设置的iso2语言代码?

推荐文章

ClickOnce困境:代码标识与安全性-该怎么办?

ClickOnce困境:代码标识与安全性-该怎么办?

推荐文章

使用IE在ASP.NEt中强制下载PDF

使用IE在ASP.NEt中强制下载PDF

推荐文章

欧氏距离

欧氏距离

推荐文章

从内容提供程序获取最常出现字段的行计数

从内容提供程序获取最常出现字段的行计数

推荐文章

如何通过文本文件到达任何用户的桌面?

如何通过文本文件到达任何用户的桌面?

推荐文章

XmlDocument的延迟加载

XmlDocument的延迟加载