dlaczego entitymanager odłącza encje tuż po

Hej,

piszę prostą aplikację z użyciem springa + jpa(hibernate). Napisałem prostą klasę DAO:

public abstract class SomeDao {

    @PersistenceContext
    protected EntityManager entityManager;

    @Transactional
    public void remove(SomeEntity obj) throws RemoveException {
        try {
            entityManager.refresh(obj);
            entityManager.remove(obj);
        } catch (Exception e) {
            throw new RemoveException(e);
        }
    }

    public SomeEntity findByPrimaryKey(Object pk) throws FinderException {
        SomeEntity obj = null;
        try {
            return entityManager.find(SomeEntity.class, pk);
        } catch (Exception e) {
            throw new FinderException(e);
        }
    }
}

Podczas usuwania encji za pomocą funkcji remove() dostaję wyjątek: java.lang.IllegalArgumentException: Entity not managed.
Jest to o tyle dziwne, że kod wygląda mniej więcej tak:

dao.remove( dao.findByPrimaryKey(someint) );

Zacząłem sprawę inwigilować bardziej i okazuje się, że obiekt pobrany za pomocą entityManager.find(); nie jest podłączony do entitymanagera (entityManager.contains(obj) zwraca false);

Co więcej, zauważyłem, że wywołanie kilka razy entityManager.find(SomeEntity.class, pk); za każdym razem odwołuje się do bazy danych.
Czyli nie dość, że find odłącza od razu encje to dodatkowo nie przechowuje ich z użyciem wzorca Identity Map.

Czy moglibyście wytłumaczyć mi to dziwne z mojego punktu widzenia zachowanie?

1. Czy metoda, w której wykonujesz "dao.remove( dao.findByPrimaryKey(someint) );" ma adnotację @Transactional ?

powinno być tak:
@Transactional
public void removeById(int id) {
dao.remove( dao.findByPrimaryKey(id) );
}

2. Jeżeli chcesz, aby liczba odwołań do bazy się zmniejszyła użyj Second Level Cache + Quary Cache

Zmodyfikowałem nawet metodę z dao:

@Transactional
    public T findByPrimaryKey(Object pk) throws FinderException {
        T obj = null;
        try {
            obj = entityManager.find(getEntityClass(), pk);
            entityManager.remove(obj);
        } catch (Exception e) {
            throw new FinderException(e);
        }
        if (obj == null) {
            throw new FinderException(getEntityClass().getName() + " with id " + pk + " not found");
        }
        return obj;
    } 

Zmienił się jedynie wyjątek, teraz jest:
java.lang.IllegalArgumentException: Removing a detached instance

Nie znam sie dokladnie na Springu i jego wsparciu dla JPA, nigdy nie uzywalem. Jednak jesli to dziala tak jak EJB, to kazde wywolanie beana powoduje wstrzykniecie swiezej instancji EntityManagera - sprawdzic mozesz debugujac i patrzac jaki hash / id ma ten entity manager.
Aby uniknac wyjatku, w metodzie remove zamiast refresh i czegostam wywolaj merge:

entityManager.remove(entityManager.merge(obj));

To zadziala tak ze merge najpierw dolacza detached obiekt do kontekstu, sprawiajc ze jest managed, i nastepnie zwraca ta instancje (tam zachodzi pare ciekawych operacji, jak tworzenie nowego obiektu, kopiowanie stanu itp itd, odsylam do specyfikacji JPA), ktory ty usuwasz. Jako ze wszystko dzieje sie w tej samej transakcji, powinno dzialac.

Dzięki za odpowiedź, zauważyłem, że merge działa - ale to nie jest chyba dobre wyjście. Wolałbym się dowiedzieć, dlaczego find() po zwróceniu obiektu odłącza go?

ps. entityManager jest ten sam

Oj oj Twoje pole EntityManager moze byc to samo, ale to moze byc tylko wrapper tworzony przez Springa, takie proxy. Mozesz podac nazwe klasy tego EM? Sprobuj wywolac metode getDelegate(), ona powinna zwrocic to co powinienes sprawdzac.

Teraz motyw z find. Jak juz napisalem, nie find usuwa z kontekstu, tylko robisz to poza transakcja. Oto co mowi specyfikacja (dobry dokument, polecam przeczytac jak sie masz zamiar zajmowac JPA na powaznie):

The find method (provided it is invoked without a lock or invoked with LockModeType.NONE)
and the getReference method are not required to be invoked within a transaction context. If an
entity manager with transaction-scoped persistence context is in use, the resulting entities will be
detached; if an entity manager with an extended persistence context is used, they will be managed. See
section 3.3 for entity manager use outside a transaction.

Jak ja wolasz bez parametru to jest wlasnie uzyty LockModeType.NONE, bo tak jest w specyfikacji. Teraz Twoje wywolanie:

dao.remove( dao.findByPrimaryKey(someint));

rozbieramy na czesci:
0. dao jest pewnie wstrzykniete przez springa, wiec moze to byc rowniez jakies proxy, ale niewazne

1. dao.findByPrimaryKey - ta metoda jest poza transakcja, i zgodnie z cytatem powyzej zwraca instancje detached
2. no i z taka instancja wolasz remove, i dostajesz po glowie

Metode remove sprobuj zaimplementowac np tak:

    @Transactional
    public void remove(SomeEntity obj) throws RemoveException {
        try {
            entityManager.remove(entityManager.getReference(obj.getId()));
        } catch (Exception e) {
            throw new RemoveException(e);
        }
    }

refresh() jest zlym wyborem poniewaz ona wybucha gdy parametr nie jest managed, co zreszta sam zauwazyles w pierwszym poscie. Jak nie zadziala powyzsza metoda, to nie ma bata, musisz zrobic merge i juz.

Spróbuj tak:

@Transactional
    public void remove(SomeEntity obj) throws RemoveException {
        try {
            entityManager.remove(entityManager.createQuery("From SomeEntity se WHERE se.id = :id").setParameter("id", obj.getId()).getSingleResult());
        } catch (Exception e) {
            throw new RemoveException(e);
        }
    }

P.S. Jakiego providera używasz (Hiberante? Toplink?)

Raz, ze bez sensu rozwiazanie, poniewaz: parsujesz zapytanie, wywalasz je do bazy i tutaj nie ma cachowania ani nic, i robisz to tyklo po to aby pobrac id i usunac z bazy. Juz merge o wiele lepszy.
Dwa, ze autor watku juz chyba sie nie interesuje co piszemy ;d