PersistentObjectException: JPA और हाइबरनेट द्वारा फेंक दिए गए को बनाए रखने के लिए अलग की गई इकाई

Question

मेरे पास एक जेपीए-फ़ारवर्ड ऑब्जेक्ट मॉडल है जिसमें कई-से-एक संबंध हैं: Accountकई हैं Transactions। A के Transactionपास एक है Account।

यहाँ कोड का एक टुकड़ा है:

@Entity
public class Transaction {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @ManyToOne(cascade = {CascadeType.ALL},fetch= FetchType.EAGER)
    private Account fromAccount;
....

@Entity
public class Account {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    @OneToMany(cascade = {CascadeType.ALL},fetch= FetchType.EAGER, mappedBy = "fromAccount")
    private Set<Transaction> transactions;

मैं एक Accountऑब्जेक्ट बनाने में सक्षम हूं , इसमें लेनदेन जोड़ें, और Accountऑब्जेक्ट को सही ढंग से जारी रखें । लेकिन, जब मैं एक लेन-देन बनाता हूं, तो पहले से ही मौजूद एक खाते का उपयोग करके और लेन-देन को जारी रखते हुए , मुझे एक अपवाद मिलता है:

इसके कारण: org.hibernate.PersistentObjectException: अलग की गई इकाई को जारी रखने के लिए: com.paulsanwald।

इसलिए, मैं ऐसा Accountव्यवहार करने में सक्षम हूं जिसमें लेनदेन शामिल है, लेकिन ऐसा लेनदेन नहीं है जिसमें ए है Account। मैंने सोचा था कि यह Accountसंलग्न नहीं हो सकता है, लेकिन यह कोड अभी भी मुझे वही अपवाद देता है:

if (account.getId()!=null) {
    account = entityManager.merge(account);
}
Transaction transaction = new Transaction(account,"other stuff");
 // the below fails with a "detached entity" message. why?
entityManager.persist(transaction);

मैं Transactionपहले से ही बनी हुई Accountवस्तु के साथ, सही तरीके से कैसे बचा सकता हूं ?

Comments

मेरे मामले में, मैं एक इकाई की आईडी सेट कर रहा था जिसे मैं एंटिटी मैनेजर का उपयोग करके जारी रखने की कोशिश कर रहा था। जब, मैंने id के लिए सेटर को हटा दिया, तो यह ठीक काम करने लगा।

— रूशी शाह

मेरे मामले में, मैं आईडी सेट नहीं कर रहा था, लेकिन एक ही खाते का उपयोग करने वाले दो उपयोगकर्ता थे, उनमें से एक ने एक इकाई (सही ढंग से) कायम रखी, और दूसरा जब बाद वाले ने उसी इकाई को बनाए रखने का प्रयास किया, तो त्रुटि उत्पन्न हुई। बनी रही।

— सर्जियोएफसी

Answer 1

यह एक विशिष्ट द्विदिश स्थिरता समस्या है। यह इस लिंक के साथ-साथ इस लिंक में अच्छी तरह से चर्चा की गई है ।

पिछले 2 लिंक के लेखों के अनुसार आपको द्विदिश संबंध के दोनों पक्षों में अपने बसने वालों को ठीक करने की आवश्यकता है। इस लिंक में वन साइड के लिए एक उदाहरण सेटर है ।

कई लिंक के लिए एक उदाहरण सेटर इस लिंक में है।

आपके द्वारा अपने निपटान को सही करने के बाद आप एंटिटी एक्सेस प्रकार को "संपत्ति" घोषित करना चाहते हैं। "संपत्ति" एक्सेस प्रकार घोषित करने के लिए सबसे अच्छा अभ्यास सदस्य संपत्तियों से सभी एनोटेशन को संबंधित गेटर्स पर ले जाना है। सतर्कता का एक बड़ा शब्द "फ़ील्ड" और "संपत्ति" एक्सेस प्रकारों को इकाई वर्ग के भीतर मिश्रण करना नहीं है अन्यथा व्यवहार JSR-317 विनिर्देशों द्वारा अपरिभाषित है।

Comments

ps: @Id एनोटेशन वह है जो हाइबरनेट का उपयोग एक्सेस प्रकार की पहचान करने के लिए करता है।

— डिएगो प्लेंटज़

अपवाद है: detached entity passed to persistसुधार में स्थिरता क्यों बनाता है कि यह काम करता है? ठीक है, निरंतरता की मरम्मत की गई थी लेकिन वस्तु अभी भी अलग है।

— गिलगमेश

@Sam, आपके स्पष्टीकरण के लिए बहुत बहुत धन्यवाद। लेकिन, मुझे अभी भी समझ नहीं आ रहा है। मैं देख रहा हूं कि 'विशेष' सेटर के बिना द्वि-दिशात्मक संबंध पर व्यंग्य नहीं किया गया है। लेकिन, मैं नहीं देखता कि वस्तु को अलग क्यों किया गया।

— गिलगमेज़

कृपया एक उत्तर पोस्ट न करें जो केवल लिंक के साथ उत्तर देता है।

— एल मैक

यह नहीं देख सकता कि यह उत्तर प्रश्न से कैसे संबंधित है?

— यूजेन लाबून

Answer 2

समाधान सरल है, बस के CascadeType.MERGEबजाय CascadeType.PERSISTया का उपयोग करें CascadeType.ALL।

मुझे भी यही समस्या हुई है और CascadeType.MERGEमेरे लिए काम किया है।

मुझे उम्मीद है कि आप छांटे गए होंगे।

Comments

हैरानी की बात है कि एक मेरे लिए भी काम किया। इसका कोई मतलब नहीं है क्योंकि CascadeType.ALL में अन्य सभी कैस्केड प्रकार शामिल हैं ... WTF? मेरे पास वसंत 4.0.4, वसंत डेटा जपा 1.8.0 और हाइबरनेट 4.X है। क्या किसी को कोई विचार है कि सभी काम क्यों नहीं करते, लेकिन MERGE करता है?

— वादिम किरिलचुक

@VadimKirilchuk यह मेरे लिए भी काम किया और यह कुल समझ में आता है। चूँकि Transaction PERSISTED है, इसलिए यह PERSIST खाते के लिए भी कोशिश करता है और यह काम नहीं करता है क्योंकि Account पहले से ही db में है। लेकिन CascadeType.MERGE के साथ खाता इसके बजाय स्वचालित रूप से विलय कर दिया जाता है।

— गन्सलिंगर

यदि आप लेन-देन का उपयोग नहीं करते हैं तो ऐसा हो सकता है।

— lanoxx

एक और समाधान: पहले से ही बनी हुई वस्तु को सम्मिलित न करने की कोशिश करें :)

— एंड्री प्लोटनिकोव

श्रीमान धन्यवाद। यदि आप संदर्भ कुंजी के लिए प्रतिबंध नहीं है, तो निरंतर वस्तु को सम्मिलित करने से बचना संभव नहीं है। तो यह एकमात्र उपाय है। फिर से धन्यवाद।

— मेकसी

Answer 3

बाल इकाई से कैस्केडिंग निकालेंTransaction , यह सिर्फ होना चाहिए:

@Entity class Transaction {
    @ManyToOne // no cascading here!
    private Account account;
}

( FetchType.EAGERइसके लिए डिफ़ॉल्ट के रूप में अच्छी तरह से हटाया जा सकता है@ManyToOne )

बस इतना ही!

क्यों? बाल इकाई पर "कैस्केड ऑल" कहकर Transactionआपको यह आवश्यक है कि प्रत्येक DB ऑपरेशन मूल इकाई के लिए प्रचारित हो Account। यदि आप करते हैं persist(transaction), तो persist(account)भी लागू किया जाएगा।

लेकिन केवल क्षणिक (नई) संस्थाओं को ही पारित किया जा सकता है persist(Transaction इस मामले में) । अलग (या अन्य गैर-क्षणिक स्थिति) वाले नहीं हो सकते हैं ( Accountइस मामले में, क्योंकि यह पहले से ही डीबी में है)।

इसलिए आपको "जारी रखने के लिए पारित इकाई अलग" अपवाद मिलता है । Accountइकाई का मतलब है! नहीं Transactionतुम बुलाओ persist।

---

आप आमतौर पर बच्चे से माता-पिता तक का प्रचार नहीं करना चाहते हैं। दुर्भाग्य से किताबों में (अच्छे में भी) और नेट के माध्यम से कई कोड उदाहरण हैं, जो वास्तव में ऐसा करते हैं। मुझे नहीं पता, क्यों ... शायद कभी-कभी बिना ज्यादा सोचे-समझे नकल कर ली जाती है ...

लगता है कि क्या होता है अगर आप remove(transaction)अभी भी उस @ManyToOne में "कैस्केड ऑल" कहते हैं? account(Btw, अन्य सभी लेनदेन के साथ!) डीबी से भी हटा दिया जाएगा। लेकिन यह आपका इरादा नहीं था, क्या यह था?

Comments

बस जोड़ना चाहते हैं, अगर आपका इरादा वास्तव में माता-पिता के साथ बच्चे को बचाने का है और बच्चे के साथ-साथ माता-पिता को भी हटा दें, जैसे व्यक्ति (माता-पिता) और पता (बच्चे) के साथ-साथ डीबी द्वारा पता लगाया गया है तो कॉल करने से पहले पर्सन को सेव करें, बस आपके लेनदेन के तरीके में पते को बचाने के लिए एक कॉल। इस तरह यह डीबी द्वारा उत्पन्न आईडी के साथ ही सहेजा जाएगा। प्रदर्शन पर कोई प्रभाव नहीं है क्योंकि हिबनेट अभी भी 2 प्रश्न बनाता है, हम सिर्फ प्रश्नों के क्रम को बदल रहे हैं।

— विकी

यदि हम कुछ भी पास नहीं कर सकते हैं तो यह सभी मामले के लिए क्या डिफ़ॉल्ट मूल्य है।

— धवनिल पटेल

Answer 4

मर्ज का उपयोग करना जोखिम भरा और मुश्किल है, इसलिए यह आपके मामले में एक गंदा काम है। आपको कम से कम यह याद रखने की आवश्यकता है कि जब आप मर्ज करने के लिए एक इकाई ऑब्जेक्ट पास करते हैं, तो यह बंद हो जाता है लेनदेन से जुड़ा होना और एक नई, अब संलग्न इकाई वापस आ जाती है। इसका मतलब यह है कि अगर किसी के पास पुरानी इकाई वस्तु अभी भी उनके कब्जे में है, तो उसमें परिवर्तन को चुपचाप नजरअंदाज कर दिया जाता है और उसे फेंक दिया जाता है।

आप यहां पूरा कोड नहीं दिखा रहे हैं, इसलिए मैं आपके लेनदेन पैटर्न की दोबारा जांच नहीं कर सकता। इस तरह की स्थिति में आने का एक तरीका यह है कि यदि आपके पास मर्ज को निष्पादित करने और जारी रखने के दौरान कोई लेनदेन सक्रिय नहीं है। उस स्थिति में दृढ़ता प्रदाता से आपके द्वारा किए गए हर JPA ऑपरेशन के लिए एक नया लेन-देन खोलने और तुरंत कॉल करने से पहले इसे बंद करने और बंद करने की अपेक्षा की जाती है। यदि यह स्थिति है, तो मर्ज पहले लेन-देन में चलाया जाएगा और फिर मर्ज विधि के वापस आने के बाद, लेन-देन पूरा हो गया है और बंद हो गया है और रिटर्न की गई इकाई अब अलग हो गई है। इसके नीचे बने रहने वाले के बाद दूसरा लेन-देन खुलेगा, और एक इकाई को संदर्भित करने का प्रयास किया जाएगा, जो अपवाद है। हमेशा अपने कोड को लेनदेन के अंदर लपेटें जब तक कि आप अच्छी तरह से नहीं जानते कि आप क्या कर रहे हैं।

कंटेनर-प्रबंधित लेनदेन का उपयोग करना कुछ इस तरह दिखाई देगा। ध्यान दें: यह मानता है कि विधि एक सत्र बीन के अंदर है और स्थानीय या दूरस्थ इंटरफ़ेस के माध्यम से कहा जाता है।

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void storeAccount(Account account) {
    ...

    if (account.getId()!=null) {
        account = entityManager.merge(account);
    }

    Transaction transaction = new Transaction(account,"other stuff");

    entityManager.persist(account);
}

Comments

मैं एक ही मुद्दे का सामना कर रहा हूं, मैंने @Transaction(readonly=false)सर्विस लेयर पर उपयोग किया है । अभी भी एक ही अंक प्राप्त कर रहा हूं,

— सेंथिल अरुमुगम SP

मैं यह नहीं कह सकता कि मैं पूरी तरह से समझता हूं कि चीजें इस तरह से क्यों काम करती हैं, लेकिन निरंतर पद्धति और एंटिटी मैपिंग को एक साथ एक ट्रांजेक्शनल एनोटेशन के अंदर देखने से मेरा मुद्दा तय हो जाता है इसलिए धन्यवाद।

— डेड्रॉन

यह वास्तव में सबसे उत्थान से बेहतर उपाय है।

— अलेक्सी मैड

Answer 5

संभवतः इस मामले में आपने accountमर्ज लॉजिक का उपयोग करके अपनी वस्तु प्राप्त की , और persistनई वस्तुओं को बनाए रखने के लिए उपयोग किया जाता है और यह शिकायत करेगा कि क्या पदानुक्रम पहले से ही बनी हुई वस्तु है। आपको saveOrUpdateइसके बजाय ऐसे मामलों में उपयोग करना चाहिए persist।

Comments

यह जेपीए है, इसलिए मुझे लगता है कि अनुरूप पद्धति .merge () है, लेकिन इससे मुझे एक ही अपवाद मिलता है। स्पष्ट होने के लिए, लेन-देन एक नई वस्तु है, खाता नहीं है।

— पॉल सानवल्ड 23

@PaulSanwald ऑब्जेक्ट mergeपर transactionउसी त्रुटि का उपयोग करना ?

— दान

वास्तव में, नहीं, मैंने गलत बात कही। यदि मैं .merge (लेन-देन) करता हूं, तो लेनदेन बिल्कुल भी जारी नहीं रहता है।

— पॉल सानवल्ड 23

@PaulSanwald हम्म, क्या आप सुनिश्चित हैं कि transactionनिरंतर नहीं था? आपने जांच कैसे की? ध्यान दें कि mergeबनी हुई वस्तु का संदर्भ वापस आ रहा है।

— डैन

ऑब्जेक्ट .merge () द्वारा लौटाया गया एक शून्य आईडी है। इसके अलावा, मैं एक .findAll () बाद में कर रहा हूं, और मेरी वस्तु वहां नहीं है।

— पॉल संवाल्ड

Answer 6

जारी रखने के लिए आईडी (पीके) पास न करें या जारी रखने के बजाय बचाने की कोशिश करें () विधि।

Comments

अच्छी सलाह! लेकिन अगर केवल id जनरेट होती है। यदि यह असाइन किया गया है तो आईडी को सेट करना सामान्य है।

— एल्डियन

यह मेरे लिए काम किया। इसके अलावा, आप TestEntityManager.persistAndFlush()एक उदाहरण प्रबंधित और स्थिर बनाने के लिए उपयोग कर सकते हैं फिर अंतर्निहित डेटाबेस के लिए दृढ़ता संदर्भ को सिंक्रनाइज़ कर सकते हैं। मूल स्रोत इकाई लौटाता है

— Anyul रिवास

Answer 7

चूंकि यह एक बहुत ही सामान्य प्रश्न है, इसलिए मैंने यह लेख लिखा है , जिस पर यह उत्तर आधारित है।

समस्या को ठीक करने के लिए आपको इन चरणों का पालन करना होगा:

1. बाल एसोसिएशन कैस्केडिंग को हटाना

इसलिए, आपको एसोसिएशन @CascadeType.ALLसे निकालने की आवश्यकता है @ManyToOne। बाल संस्थाओं को माता-पिता संघों के लिए झरना नहीं बनाना चाहिए। केवल अभिभावक संस्थाओं को ही बाल संस्थाओं के लिए कैस्केड करना चाहिए।

@ManyToOne(fetch= FetchType.LAZY)

ध्यान दें कि मैंने निर्धारित किया है fetch विशेषता है FetchType.LAZYक्योंकि उत्सुकता प्रदर्शन के लिए बहुत खराब है ।

2. एसोसिएशन के दोनों किनारों को सेट करें

जब भी आपके पास एक द्विदिश संघ होता है, तो आपको दोनों पक्षों का उपयोग करके सिंक्रनाइज़ करना होगा addChildremoveChild मूल इकाई में और विधियों :

public void addTransaction(Transaction transaction) {
    transcations.add(transaction);
    transaction.setAccount(this);
}

public void removeTransaction(Transaction transaction) {
    transcations.remove(transaction);
    transaction.setAccount(null);
}

द्विदिश संघ के दोनों सिरों को सिंक्रनाइज़ करना क्यों महत्वपूर्ण है, इसके बारे में अधिक विवरण के लिए, इस लेख को देखें ।

Answer 8

अपनी इकाई परिभाषा में, आप @JoinColumn में Accountशामिल होने के लिए निर्दिष्ट नहीं कर रहे हैं Transaction। आप कुछ इस तरह चाहते हैं:

@Entity
public class Transaction {
    @ManyToOne(cascade = {CascadeType.ALL},fetch= FetchType.EAGER)
    @JoinColumn(name = "accountId", referencedColumnName = "id")
    private Account fromAccount;
}

संपादित करें: ठीक है, मुझे लगता है कि यदि आप @Tableअपनी कक्षा में एनोटेशन का उपयोग कर रहे हैं तो यह उपयोगी होगा । हे। :)

Comments

हाँ, मुझे नहीं लगता कि यह वही है, सभी समान, मैंने @JoinColumn (नाम = "fromAccount_id", referencedColumnName = "id") जोड़ा और यह काम नहीं किया :)।

— पॉल संवलद

हाँ, मैं आमतौर पर तालिकाओं को मैप करने के लिए मैपिंग xml फ़ाइल का उपयोग नहीं करता हूं, इसलिए मैं आमतौर पर मान लेता हूं कि यह एनोटेशन आधारित है। लेकिन अगर मुझे अनुमान लगाना था, तो आप टेबल के लिए एंटिटीज़ को मैप करने के लिए एक hibernate.xml का उपयोग कर रहे हैं, है ना?

— नेमसिसएक्स00

नहीं, मैं स्प्रिंग डेटा JPA का उपयोग कर रहा हूं, इसलिए यह सभी एनोटेशन आधारित है। मेरे पास दूसरी तरफ "मैपेडबी" एनोटेशन है: @OneToMany (cascade = {CascadeType.ALL}, fetch = FetchType.EAGER, mappedBy = "fromAccount")

— पॉल सैनवल्ड

Answer 9

यहां तक ​​कि अगर आपके एनोटेशन को एक-से-कई संबंधों को ठीक से प्रबंधित करने के लिए सही ढंग से घोषित किया गया है, तो भी आप इस सटीक अपवाद का सामना कर सकते हैं। जब Transactionतक संलग्न डेटा मॉडल में एक नई चाइल्ड ऑब्जेक्ट को जोड़ते हैं, तब तक आपको प्राथमिक कुंजी मान प्रबंधित करने की आवश्यकता होगी - जब तक कि आप करने वाले नहीं हैं । यदि आप कॉल करने से पहले घोषित की गई बाल इकाई के लिए एक प्राथमिक कुंजी मूल्य की आपूर्ति करते हैं persist(T), तो आप इस अपवाद का सामना करेंगे।

@Entity
public class Transaction {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
....

इस स्थिति में, एनोटेशन यह घोषित कर रहे हैं कि डेटाबेस प्रविष्टि पर इकाई के प्राथमिक प्रमुख मूल्यों की पीढ़ी का प्रबंधन करेगा। अपने आप को प्रदान करना (जैसे कि ईद के सेटर के माध्यम से) इस अपवाद का कारण बनता है।

वैकल्पिक रूप से, लेकिन प्रभावी रूप से एक ही, इस एनोटेशन घोषणा में एक ही अपवाद होता है:

@Entity
public class Transaction {
    @Id
    @org.hibernate.annotations.GenericGenerator(name="system-uuid", strategy="uuid")
    @GeneratedValue(generator="system-uuid")
    private Long id;
....

इसलिए, idअपने एप्लिकेशन कोड में मूल्य तब सेट न करें जब यह पहले से प्रबंधित हो।

Answer 10

अगर कुछ भी मदद नहीं करता है और आप अभी भी इस अपवाद को प्राप्त कर रहे हैं, तो अपने equals()तरीकों की समीक्षा करें - और इसमें बाल संग्रह शामिल न करें। खासकर यदि आपके पास एम्बेडेड संग्रह की गहरी संरचना है (जैसे A में Bs, B में Cs, आदि शामिल हैं)।

के उदाहरण में Account -> Transactions:

  public class Account {

    private Long id;
    private String accountName;
    private Set<Transaction> transactions;

    @Override
    public boolean equals(Object obj) {
      if (this == obj)
        return true;
      if (obj == null)
        return false;
      if (!(obj instanceof Account))
        return false;
      Account other = (Account) obj;
      return Objects.equals(this.id, other.id)
          && Objects.equals(this.accountName, other.accountName)
          && Objects.equals(this.transactions, other.transactions); // <--- REMOVE THIS!
    }
  }

ऊपर के उदाहरण में लेनदेन को equals()चेक से हटा दें । इसका कारण यह है कि हाइबरनेट का अर्थ होगा कि आप पुरानी वस्तु को अपडेट करने की कोशिश नहीं कर रहे हैं, लेकिन जब भी आप बच्चे के संग्रह पर तत्व बदलते हैं, तो आप एक नई ऑब्जेक्ट को जारी रखने के लिए पास करते हैं।
बेशक यह समाधान सभी अनुप्रयोगों में फिट नहीं होगा और आपको सावधानीपूर्वक डिजाइन करना चाहिए जिसे आप equalsऔर hashCodeविधियों में शामिल करना चाहते हैं ।

Answer 11

शायद यह OpenJPA की बग है, जब रोलबैक यह @Version फ़ील्ड रीसेट करता है, लेकिन PCVersion यह सही है। मेरे पास एक AbstraceEntity है जिसने @Version फ़ील्ड घोषित किया है। मैं pcVersionInit क्षेत्र को रीसेट करके इसे हल कर सकता हूं। लेकिन यह एक अच्छा विचार नहीं है। मुझे लगता है कि यह काम नहीं करता है जब कैस्केड बनी रहती है।

    private static Field PC_VERSION_INIT = null;
    static {
        try {
            PC_VERSION_INIT = AbstractEntity.class.getDeclaredField("pcVersionInit");
            PC_VERSION_INIT.setAccessible(true);
        } catch (NoSuchFieldException | SecurityException e) {
        }
    }

    public T call(final EntityManager em) {
                if (PC_VERSION_INIT != null && isDetached(entity)) {
                    try {
                        PC_VERSION_INIT.set(entity, false);
                    } catch (IllegalArgumentException | IllegalAccessException e) {
                    }
                }
                em.persist(entity);
                return entity;
            }

            /**
             * @param entity
             * @param detached
             * @return
             */
            private boolean isDetached(final Object entity) {
                if (entity instanceof PersistenceCapable) {
                    PersistenceCapable pc = (PersistenceCapable) entity;
                    if (pc.pcIsDetached() == Boolean.TRUE) {
                        return true;
                    }
                }
                return false;
            }

Answer 12

आपको प्रत्येक खाते के लिए लेनदेन सेट करना होगा।

foreach(Account account : accounts){
    account.setTransaction(transactionObj);
}

या यह बहुत (यदि उपयुक्त हो) आईडी को कई तरफ से शून्य करने के लिए पर्याप्त है।

// list of existing accounts
List<Account> accounts = new ArrayList<>(transactionObj.getAccounts());

foreach(Account account : accounts){
    account.setId(null);
}

transactionObj.setAccounts(accounts);

// just persist transactionObj using EntityManager merge() method.

Answer 13

cascadeType.MERGE,fetch= FetchType.LAZY

Comments

हाय जेम्स और आपका स्वागत है, आपको कोशिश करनी चाहिए और कोड से बचने के लिए केवल उत्तर देना चाहिए। कृपया बताएं कि यह प्रश्न में बताई गई समस्या (और जब यह लागू हो या न हो, एपीआई स्तर आदि) को हल करता है।

— मार्टन बॉड्यूज

VLQ समीक्षक: meta.stackoverflow.com/questions/260411/… देखें । कोड-ओनली उत्तर विलोपन का गुणन नहीं करते हैं, "लुक ओके" का चयन करने के लिए उचित कार्यवाही है।

— नाथन ह्यूजेस

Answer 14

मेरा स्प्रिंग डेटा JPA- आधारित उत्तर: मैंने बस @Transactionalअपनी बाहरी पद्धति में एक एनोटेशन जोड़ा है ।

यह काम क्यों करता है

बाल इकाई तुरंत बंद हो रही थी क्योंकि कोई सक्रिय हाइबरनेट सत्र संदर्भ नहीं था। स्प्रिंग (डेटा जेपीए) लेनदेन प्रदान करना सुनिश्चित करता है कि हाइबरनेट सत्र मौजूद है।

संदर्भ:

https://vladmihalcea.com/a-beginners-guide-to-jpa-hibernate-entity-state-transitions/

Answer 15

मेरे मामले में जब मैं लगातार पद्धति का उपयोग करता था तो मैं लेनदेन कर रहा था । बदलने के बारे में जारी रहती है को बचाने के लिए विधि है, यह संकल्प लिया गया।

Answer 16

यदि उपरोक्त समाधान केवल एक बार काम नहीं करते हैं, तो इकाई वर्ग के गेट्टर और सेटर के तरीकों पर टिप्पणी करें और आईडी (प्राथमिक कुंजी) का मान सेट न करें, तो यह काम करेगा।

Answer 17

@OneToMany (mappedBy = "xxxx", झरना = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REMOVE}) ने मेरे लिए काम किया।

Answer 18

अगले से पहले निर्भर वस्तु को बचाने के द्वारा हल किया गया।

यह मेरे साथ हुआ था क्योंकि मैं ईद सेट नहीं कर रहा था (जो ऑटो उत्पन्न नहीं हुआ था)। और संबंध @ManytoOne से बचाने की कोशिश कर रहा है