PersistentObjectException: odłączony byt przekazany do trwałego wyrzucenia przez JPA i Hibernację

Mam model obiektów utrwalony przez JPA, który zawiera relację wiele do jednego: Accountma wiele Transactions. A Transactionma jeden Account.

Oto fragment kodu:

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

Jestem w stanie utworzyć Accountobiekt, dodać do niego transakcje i Accountpoprawnie utrwalić obiekt. Ale kiedy tworzę transakcję, używając istniejącego już utrwalonego Konta i utrwalając Transakcję , otrzymuję wyjątek:

Przyczyna: org.hibernate.PersistentObjectException: odłączony byt przekazany do trwałego: com.paulsanwald.Account at org.hibernate.event.internal.DefaultPersistEventListener.onPersist (DefaultPersistEventListener.java:141)

Tak więc jestem w stanie utrzymać Accounttransakcję zawierającą transakcje, ale nie transakcję zawierającą transakcję Account. Myślałem, że dzieje się tak, ponieważ Accountmoże nie być dołączony, ale ten kod wciąż daje mi ten sam wyjątek:

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

Jak mogę poprawnie zapisać obiekt Transactionpowiązany z już utrwalonym Accountobiektem?

Jest to typowy problem z dwukierunkową spójnością. Jest dobrze omówione w tym linku, a także w tym linku.

Zgodnie z artykułami w poprzednich 2 linkach musisz naprawić seterów po obu stronach relacji dwukierunkowej. Przykładowy setter dla jednej strony znajduje się w tym łączu.

Przykładowy setter dla strony Many znajduje się w tym łączu.

Po poprawieniu ustawień należy zadeklarować, że typ dostępu encji to „Właściwość”. Najlepszą praktyką do deklarowania typu dostępu „Właściwość” jest przeniesienie WSZYSTKICH adnotacji z właściwości elementu do odpowiednich modułów pobierających. Dużym ostrzeżeniem jest, aby nie mieszać typów dostępu „Pole” i „Właściwość” w klasie encji, w przeciwnym razie zachowanie nie jest określone w specyfikacji JSR-317.

Rozwiązanie jest proste, wystarczy użyć CascadeType.MERGEzamiast CascadeType.PERSISTlub CascadeType.ALL.

Miałem ten sam problem i CascadeType.MERGEpracował dla mnie.

Mam nadzieję, że jesteś posortowany.

Usuń kaskadę z elementu potomnegoTransaction , powinno to być po prostu:

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

( FetchType.EAGERmożna usunąć, jak to domyślnie dla @ManyToOne)

To wszystko!

Czemu? Mówiąc „kaskadowo WSZYSTKO” na encji podrzędnej, wymagasz Transaction, aby każda operacja DB była propagowana do encji nadrzędnej Account. Jeśli to zrobisz persist(transaction), persist(account)zostanie również wywołane.

Ale tylko przejściowe (nowe) byty mogą być przekazywane persist( Transactionw tym przypadku). Odłączone (lub inne nieprzemijające stany) mogą nie ( Accountw tym przypadku, ponieważ są już w DB).

Dlatego otrzymujesz wyjątek „odłączony byt przekazany do trwałego” . AccountJednostka rozumie! Nie ten Transaction, do którego dzwonisz persist.

Na ogół nie chcesz rozmnażać się z dziecka na rodzica. Niestety istnieje wiele przykładów kodu w książkach (nawet w dobrych) i przez sieć, które właśnie to robią. Nie wiem, dlaczego ... Może czasami po prostu kopiowałem w kółko bez większego zastanowienia ...

Zgadnij, co się stanie, jeśli remove(transaction)nadal będziesz mówić „kaskadowo WSZYSTKO” w tym @ManyToOne? account(Btw, wszystkie inne transakcje!) Również zostaną usunięte z bazy danych. Ale to nie był twój cel, prawda?

Korzystanie ze scalania jest ryzykowne i trudne, więc w twoim przypadku jest to nieprzyjemne obejście. Musisz przynajmniej pamiętać, że po przekazaniu obiektu encji do scalenia przestaje on być dołączany do transakcji, a zamiast tego zwracany jest nowy, teraz dołączony byt. Oznacza to, że jeśli ktoś nadal ma w posiadaniu stary obiekt bytu, zmiany w nim są po cichu ignorowane i wyrzucane po zatwierdzeniu.

Nie wyświetlasz tutaj pełnego kodu, więc nie mogę dokładnie sprawdzić wzorca transakcji. Jednym ze sposobów na osiągnięcie takiej sytuacji jest to, że podczas wykonywania scalania i utrzymywania transakcji nie jest aktywna. W takim przypadku oczekuje się, że dostawca trwałości otworzy nową transakcję dla każdej wykonywanej operacji JPA oraz natychmiast zatwierdzi i zamknie ją przed powrotem połączenia. W takim przypadku scalanie zostanie uruchomione w pierwszej transakcji, a następnie po zwróceniu metody scalania transakcja zostanie zakończona i zamknięta, a zwrócona jednostka zostanie odłączona. Utrwalenie poniżej otworzy następnie drugą transakcję i spróbuje odwołać się do jednostki, która jest odłączona, dając wyjątek. Zawsze zawijaj kod w transakcji, chyba że dobrze wiesz, co robisz.

Korzystając z transakcji zarządzanej przez kontener, wyglądałoby to tak. Uwaga: zakłada się, że metoda znajduje się w komponencie bean sesji i jest wywoływana przez interfejs lokalny lub zdalny.

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

Prawdopodobnie w tym przypadku accountobiekt został uzyskany przy użyciu logiki scalania i persistsłuży do utrwalania nowych obiektów i będzie narzekać, jeśli hierarchia ma już utrwalony obiekt. W saveOrUpdatetakich przypadkach powinieneś użyć zamiast persist.

Nie przekazuj id (pk), aby utrwalić metodę, ani spróbuj metody save () zamiast persist ().

Ponieważ jest to bardzo częste pytanie, napisałem ten artykuł , na którym opiera się ta odpowiedź.

Aby rozwiązać problem, wykonaj następujące kroki:

1. Usuwanie kaskadowego powiązania dzieci

Tak, trzeba usunąć @CascadeType.ALLze @ManyToOnestowarzyszenia. Podmioty potomne nie powinny kaskadować do stowarzyszeń nadrzędnych. Tylko jednostki nadrzędne powinny być kaskadowane do jednostek podrzędnych.

@ManyToOne(fetch= FetchType.LAZY)

Zauważ, że ustawiłem ten fetchatrybut na, FetchType.LAZYponieważ chętne pobieranie jest bardzo niekorzystne dla wydajności .

2. Ustaw obie strony stowarzyszenia

Ilekroć masz powiązanie dwukierunkowe, musisz zsynchronizować obie strony za pomocą addChildi removeChildmetod w encji nadrzędnej:

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

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

Aby uzyskać więcej informacji o tym, dlaczego ważna jest synchronizacja obu końców powiązania dwukierunkowego, zapoznaj się z tym artykułem .

W definicji encji nie określasz @JoinColumn dla Accountprzyłączonego do a Transaction. Będziesz chciał coś takiego:

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

EDYCJA: Cóż, myślę, że byłoby to przydatne, gdybyś używał @Tableadnotacji na swojej klasie. Heh :)

Nawet jeśli adnotacje są zadeklarowane poprawnie, aby właściwie zarządzać relacją jeden do wielu, nadal możesz napotkać ten precyzyjny wyjątek. Podczas dodawania nowego obiektu podrzędnego Transactiondo dołączonego modelu danych należy zarządzać wartością klucza podstawowego - chyba że nie należy tego robić . Jeśli podasz wartość klucza podstawowego dla encji podrzędnej zadeklarowanej w następujący sposób przed wywołaniem persist(T), napotkasz ten wyjątek.

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

W tym przypadku adnotacje deklarują, że baza danych będzie zarządzać generowaniem wartości klucza podstawowego jednostki po wstawieniu. Podanie jednego (na przykład za pomocą narzędzia do ustawiania identyfikatora) powoduje ten wyjątek.

Alternatywnie, ale faktycznie tak samo, ta deklaracja adnotacji powoduje ten sam wyjątek:

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

Dlatego nie ustawiaj idwartości w kodzie aplikacji, gdy jest ona już zarządzana.

Jeśli nic nie pomaga i nadal występuje ten wyjątek, przejrzyj swoje equals()metody - i nie uwzględniaj w nim kolekcji podrzędnej. Zwłaszcza jeśli masz głęboką strukturę osadzonych kolekcji (np. A zawiera Bs, B zawiera Cs itp.).

Na przykład 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!
    }
  }

W powyższym przykładzie usuń transakcje z equals()czeków. Wynika to z faktu, że hibernacja oznacza, że ​​nie próbujesz aktualizować starego obiektu, ale przekazujesz nowy obiekt, aby zachować go przy każdej zmianie elementu w kolekcji potomnej.
Oczywiście te rozwiązania nie będą pasować do wszystkich aplikacji i należy dokładnie zaprojektować to, co chcesz uwzględnić w metodach equalsi hashCode.

Być może jest to błąd OpenJPA. Po przywróceniu resetuje pole @Version, ale pcVersionInit pozostaje prawdą. Mam AbstraceEntity, który zadeklarował pole @Version. Mogę to obejść, resetując pole pcVersionInit. Ale to nie jest dobry pomysł. Myślę, że to nie działa, gdy ma się element utrzymujący kaskadę.

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

Musisz ustawić transakcję dla każdego konta.

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

Lub może wystarczyć (jeśli to konieczne), aby ustawić identyfikatory na null z wielu stron.

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

Moja odpowiedź oparta na JPA z Spring Data: po prostu dodałem @Transactionaladnotację do mojej zewnętrznej metody.

Dlaczego to działa?

Podmiot potomny natychmiast się odłączał, ponieważ nie istniał aktywny kontekst sesji hibernacji. Podanie transakcji wiosennej (dane JPA) zapewnia obecność sesji hibernacji.

Odniesienie:

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

W moim przypadku popełniałem transakcję, gdy użyto metody persist . Po zmianie metody keep to save problem został rozwiązany.

Jeśli powyższe rozwiązania nie działają, wystarczy raz skomentować metody pobierające i ustawiające klasy encji i nie ustawiać wartości id. (Klucz podstawowy). To zadziała.

@OneToMany (mappedBy = "xxxx", cascade = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REMOVE}) działało dla mnie.

Rozwiązane przez zapisanie obiektu zależnego przed następnym.

Stało się tak, ponieważ nie ustawiałem identyfikatora (który nie został wygenerowany automatycznie). i próba zapisania w relacji @ManytoOne