PersistentObjectException: JPA ve Hazırda Beklet tarafından atılan kalıcılığa geçirilen bağımsız varlık

Bire bir ilişki içeren bir JPA-kalıcı nesne modeli var: bir Accountçok var Transactions. A'nın Transactionbir tane var Account.

İşte kod pasajı:

@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;

Bir Accountnesne oluşturabiliyorum , ona işlemler ekleyebiliyorum ve Accountnesneyi doğru şekilde koruyabiliyorum . Ben, bir hareket oluşturmak Fakat zaten varolan Hesabı ısrar kullanarak , ve devam eden İşlem , bir istisna olsun:

Nedeni: org.hibernate.PersistentObjectException: bağımsız varlık devam etmek için geçti: org.hibernate.event.internal.DefaultPersistEventListener.onPersist adresindeki com.paulsanwald.Account (DefaultPersistEventListener.java:141)

Yani, Accountişlemleri içeren bir devam edebiliyoruz , ancak bir Account. Bunun Accountekli olmayabilir çünkü olduğunu düşündüm , ama bu kod hala bana aynı istisnayı verir:

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);

TransactionZaten var olan bir Accountnesneyle ilişkili bir a'yı nasıl doğru şekilde kaydedebilirim ?

Bu tipik bir çift yönlü tutarlılık problemidir. İyi tartışılmıştır Bu bağlantıyı yanı sıra bu bağlantı.

Önceki 2 bağlantıdaki makalelere göre, çift yönlü ilişkinin her iki tarafındaki ayarlayıcılarınızı düzeltmeniz gerekir. Bir taraf için örnek ayarlayıcı bu bağlantıda.

Birçok taraf için örnek ayarlayıcı bu bağlantıda.

Ayarlayıcılarınızı düzelttikten sonra Varlık erişim türünü "Mülk" olarak bildirmek istersiniz. "Mülk" erişim türünü bildirmenin en iyi yolu, TÜM ek açıklamaları üye özelliklerinden ilgili alıcılara taşımaktır. Dikkat edilmesi gereken önemli bir nokta, "Field" ve "Property" erişim türlerini varlık sınıfı içinde karıştırmamaktır, aksi takdirde davranış JSR-317 belirtimleriyle tanımlanmamıştır.

Çözüm basit, sadece veya CascadeType.MERGEyerine kullanın .CascadeType.PERSISTCascadeType.ALL

Aynı sorunu yaşadım ve CascadeType.MERGEbenim için çalıştım.

Umarım sıralanırsın.

Basamaklı varlığı alt kuruluştan kaldırınTransaction , yalnızca şöyle olmalıdır:

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

( FetchType.EAGERvarsayılan olarak kaldırılabilir @ManyToOne)

Bu kadar!

Neden? Alt varlıkta "basamakla TÜMÜ" diyerek Transaction, her DB işleminin üst varlığa yayılmasını gerektirir Account. Eğer yaparsan persist(transaction),persist(account) çağrılacaktır.

Ancak yalnızca geçici (yeni) varlıklara geçilebilir persist( Transactionbu durumda). Ayrılmış (veya diğer geçici olmayan durum) olanlar ( Accountbu durumda, zaten DB'de olduğu gibi ) olmayabilir .

Bu nedenle istisna elde edersiniz "müstakil varlık devam etmek için geçti" . AccountVarlık kastedilmektedir! TransactionAradığınız kişi değil persist.

Genellikle çocuktan ebeveyne yayılmak istemezsiniz. Ne yazık ki, kitaplarda (iyi olanlarda bile) ve internette tam olarak bunu yapan birçok kod örneği vardır. Bilmiyorum, neden ... Belki bazen fazla düşünmeden basitçe tekrar tekrar kopyaladım ...

Sanırım remove(transaction)o @ManyToOne içinde hala "TÜM basamakla" sahipseniz ne olur ? account(Btw, tüm diğer işlemler ile!) Yanı DB'den silinecektir. Ama niyetin bu değildi, değil mi?

Birleştirme kullanmak riskli ve zorlayıcıdır, bu nedenle durumunuzda kirli bir çözümdür. En azından bir varlık nesnesini birleştirmek için ilettiğinizde, işleme eklenmeyi durdurduğunu ve bunun yerine şimdi ekli yeni bir varlığın döndürüldüğünü hatırlamanız gerekir . Bu, herhangi birinin eski varlık nesnesini hala elinde bulundurması durumunda, nesnede yapılan değişiklikler sessizce göz ardı edilir ve taahhütte atılır.

Kodun tamamını burada göstermiyorsunuz, bu nedenle işlem deseninizi iki kez kontrol edemiyorum. Böyle bir duruma ulaşmanın bir yolu, birleştirme işlemini gerçekleştirirken ve devam ederken etkin bir işleminiz yoksa. Bu durumda, kalıcılık sağlayıcısının gerçekleştirdiğiniz her JPA işlemi için yeni bir işlem açması ve çağrı geri dönmeden hemen önce işlem yapması ve kapatması beklenir. Bu durumda, birleştirme ilk işlemde çalıştırılır ve birleştirme yöntemi döndükten sonra işlem tamamlanır ve kapatılır ve döndürülen varlık şimdi ayrılır. Altındaki kalıcılık, daha sonra ikinci bir işlem açacak ve ayrılan bir varlığa başvurmaya çalışarak bir istisna verecektir. Ne yaptığınızı çok iyi bilmiyorsanız, kodunuzu her zaman bir işlemin içine sarın.

Kapsayıcı tarafından yönetilen işlem kullanıldığında böyle bir şey olur. Not: Bu, yöntemin bir oturum çekirdeğinin içinde olduğunu ve Yerel veya Uzak arabirim yoluyla çağrıldığını varsayar.

@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);
}

Muhtemelen bu durumda accountbirleştirme mantığını kullanarak nesnenizi elde persistetmişsinizdir ve yeni nesneleri sürdürmek için kullanılır ve hiyerarşinin zaten var olan bir nesneye sahip olup olmadığından şikayet eder. Bunun saveOrUpdateyerine bu gibi durumlarda kullanmalısınız persist.

Persist yöntemine id (pk) iletmeyin veya persist () yerine save () yöntemini denemeyin.

Bu çok yaygın bir soru olduğundan, bu cevabın dayandığı bu makaleyi yazdım .

Sorunu çözmek için şu adımları uygulamanız gerekir:

1. Alt ilişkilendirme kaldırılıyor

Yani, kaldırmak gerekir @CascadeType.ALLdan @ManyToOnedernek. Alt varlıklar ebeveyn derneklerine geçiş yapmamalıdır. Yalnızca ebeveyn varlıklar çocuk varlıklar için basamaklandırılmalıdır.

@ManyToOne(fetch= FetchType.LAZY)

fetchÖzelliği ayarladığım için dikkat edin FetchType.LAZYçünkü istekli getirme performans için çok kötü .

2. Birliğin iki tarafını da ayarlayın

İki yönlü bir ilişkilendirmeniz olduğunda, üst varlıktaki her iki tarafı addChildve removeChildyöntemleri kullanarak senkronize etmeniz gerekir :

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

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

İki yönlü bir ilişkilendirmenin her iki ucunu da senkronize etmenin neden önemli olduğu hakkında daha fazla bilgi için bu makaleye göz atın .

Senin varlık tanımı içinde belirterek değiliz @JoinColumn için Accountbir birleştirilebilir Transaction. Bunun gibi bir şey isteyeceksiniz:

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

DÜZENLEME: Şey, sanırım @Tablesınıfınızda ek açıklama kullanıyorsanız bu yararlı olurdu . Heh. :)

Ek açıklamalarınızın bire çok ilişkisini düzgün bir şekilde yönettiği bildirilse bile bu kesin istisna ile karşılaşabilirsiniz. Yeni bir alt nesne eklerken, Transaction, ekli bir veri modeline birincil anahtar değerini yönetmek gerekir - Eğer gerekmiyor sürece . Aramadan önce aşağıdaki gibi bildirilen bir alt varlık için birincil anahtar değeri sağlarsanız persist(T), bu istisna ile karşılaşırsınız.

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

Bu durumda ek açıklamalar, veritabanının ekleme sonrasında varlığın birincil anahtar değerlerinin oluşturulmasını yöneteceğini bildirir. Kendinize (örneğin Kimlik ayarlayıcı aracılığıyla) sağlamak bu istisnayı doğurur.

Alternatif olarak, ancak etkili bir şekilde aynı, bu ek açıklama bildirimi aynı istisna ile sonuçlanır:

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

Bu nedenle, idzaten yönetiliyorken uygulama kodunuzdaki değeri ayarlamayın .

Hiçbir şey yardımcı olmazsa ve hala bu istisnayı alıyorsanız, equals()yöntemlerinizi gözden geçirin ve buna çocuk koleksiyonu eklemeyin. Özellikle gömülü koleksiyonların derin yapısına sahipseniz (örneğin A, Bs içerir, B C içerir, vb.).

Örnek 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!
    }
  }

Yukarıdaki örnekte, equals()çeklerden işlemleri kaldırın . Bunun nedeni, hazırda bekletme modunun eski nesneyi güncellemeye çalışmadığınızı ima etmesi, ancak alt koleksiyondaki öğeyi her değiştirdiğinizde kalıcı olarak yeni bir nesne geçirmenizdir.
Tabii ki bu çözümler tüm uygulamalara uymayacak ve equalsve hashCodeyöntemlerine dahil etmek istediğiniz şeyi dikkatlice tasarlamalısınız .

Belki OpenJPA'nın hatası, Geri alma işlemi @Version alanını sıfırlar, ancak pcVersionInit doğru kalır. @Version alanını bildiren bir AbstraceEntity var. PcVersionInit alanını sıfırlayarak bu sorunu çözebilirim. Ama bu iyi bir fikir değil. Bence kademeli varlık var olduğunda işe yaramaz.

    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;
            }

Her Hesap için İşlem ayarlamanız gerekir.

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

Veya kimlikleri birçok tarafta null değerine ayarlamak için (uygunsa) yeterli olabilir.

// 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.

cascadeType.MERGE,fetch= FetchType.LAZY

Bahar Verilerim JPA tabanlı yanıt: Basitçe bir @Transactional Dış yöntemime açıklama .

Neden çalışıyor?

Etkin Hazırda Bekletme Oturumu içeriği olmadığından alt öğe hemen ayrılıyordu. Bir Yay (Veri JPA) işlemi sağlamak Hazırda Bekletme Oturumunun var olmasını sağlar.

Referans:

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

Benim durumumda ben işlem yapılıyor edildi devam etmesi yöntem kullanılmıştır. Değişen Açık inat etmek kurtarmak yöntemi, bu giderilmiş var.

Yukarıdaki çözümler yalnızca bir kez işe yaramazsa, varlık sınıfının alıcı ve ayarlayıcı yöntemlerini yorumlayın ve id değerini ayarlamayın. (Birincil anahtar) O zaman bu işe yarayacaktır.

@OneToMany (mappedBy = "xxxx", cascade = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REMOVE}) benim için çalıştı.

Bağımlı nesneyi bir sonrakinden önce kaydederek çözüldü.

Bu benim başıma geldi çünkü ID ayarlamıyordum (otomatik olarak oluşturulmadı). ve @ManytoOne ilişkisi ile kurtarmaya çalışıyor