5
हाइबरनेट इकाई जो मैं डेटाबेस (ओरेकल) में सहेज रहा हूं, बहुत जटिल संबंध हैं, इस अर्थ में कि इसमें कई संबंधित संस्थाएं हैं। यह कुछ इस तरह दिखता ...जटिल संबंधों के साथ इकाई को सहेजते समय StaleStateException
@Table(name = "t_HOP_CommonContract")
public class Contract {
@Id
private ContractPK id;
@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
@PrimaryKeyJoinColumn
private ContractGroupMember contractGroupMember;
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
@JoinColumns({
@JoinColumn(name = "TransactionId", referencedColumnName = "TransactionId"),
@JoinColumn(name = "PrimaryContractId", referencedColumnName = "PrimaryContractId")
})
@Fetch(FetchMode.SUBSELECT)
private List<ContractLink> contractLinks;
// . . . . . . .
// A couple of more one to many relationships
// Entity getters etc.
}
मैं भी इस तरह के रूप में और अधिक संस्थाओं की एक जोड़ी है ...
@Table(name = "t_HOP_TRS")
public class TotalReturnSwap {
@Id
private ContractPK id;
// Entity Getters etc.
}
चाल मैं में Contract और TotalReturnSwap संस्थाओं के हठ करना है वह यह है कि वही लेनदेन
कभी-कभी यह उन इकाइयों का समूह हो सकता है जिन्हें एक ही लेनदेन में जारी रखा जाना चाहिए।
मैंने TotalReturnSwap इकाई को सहेजने पर निम्नलिखित अपवाद को देखा है (जो Contract इकाई को सहेजने के बाद हमेशा किया जाता है)।
org.springframework.orm.hibernate3.HibernateOptimisticLockingFailureException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; nested exception is
org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:675) \
at org.springframework.orm.hibernate3.HibernateTransactionManager.convertHibernateAccessException(HibernateTransactionManager.java:793)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:664)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:147)
at com.rbs.fcg.publishing.DownstreamContractBusinessEventPostingService.performTDWPersistenceForContracts(DownstreamContractBusinessEventPostingService.java:102)
at com.rbs.fcg.publishing.DownstreamContractBusinessEventPostingService.persistContractBusinessEvent(DownstreamContractBusinessEventPostingService.java:87)
at com.rbs.fcg.publishing.DownstreamContractBusinessEventPostingService.publish(DownstreamContractBusinessEventPostingService.java:67)
at com.rbs.fcg.publishing.PublishingProcessor.publish(PublishingProcessor.java:76)
at com.rbs.fcg.publishing.PublishingProcessor.process(PublishingProcessor.java:52)
at com.rbs.are.MultiThreadedQueueItemProcessor$2.run(MultiThreadedQueueItemProcessor.java:106)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:85)
at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:70)
अब कुछ बिंदुओं कि सवालों का जवाब है, जबकि मदद मिल सकती है:
- मैं केवल बचत कर रहा हूँ (डालने) डेटाबेस में संस्थाओं - कभी नहीं अद्यतन करने/हटाने/पढ़ने
- मैं अलग करने के लिए सक्षम किया गया है यह अपवाद भी एकल थ्रेडेड वातावरण में है, इसलिए यह एक बहु-थ्रेडिंग की तरह नहीं दिखता है, भले ही हमारा एप्लिकेशन बहु-थ्रेडेड
बारे में # 5, हम इसे कैसे हल कर सकते हैं से objectA के एक ताजा सहायता को पुनः प्राप्त है? – Stony
@ सोंटी शायद एक 'ताज़ा करें() '? – Michael
@ माइकल मेरी समस्या 2 धागे एक ही पीओ को एक ही समय में संशोधित करती हैं; इसलिए जब पीओ को # 5 कारण के रूप में सहेजें, अपवाद फेंक दें। तो जब ताज़ा करें() मामले में? यदि सहेजने से पहले(), पीओ के लिए परिवर्तन अभी खत्म हो जाएगा। अंत में, मैंने अपनी समस्या को हल करने के लिए लॉक LockMode.PESSIMISTIC_WRITE लॉक का उपयोग किया। किसी के पास बेहतर समाधान है? – Stony