Kiedy używać Spring @ Transactional (propagacja = Propagacja.SUPPORTS)?

Według wiosennej javadoc @Transactional(propagation = Propagation.SUPPORTS)Kiedy używać Spring @ Transactional (propagacja = Propagacja.SUPPORTS)?

wsparcie bieżącej transakcji, wykonać bez transakcyjnie jeśli żaden istnieje. Analogicznie do atrybutu transakcji EJB o tej samej nazwie.

Wydaje się, że mogę po prostu zadeklarować metody bez transactionaly i po prostu być z nim zrobić, więc moje pytania są.

Jakie są sytuacje, w których propagacja SUPPORTS jest potrzebna?
Jaki jest sens propagacji Supportów?

Czy ktoś może podać przykład/scenariusz w świecie rzeczywistym, w którym WSPARCIE były rzeczywiście przydatne?

Źródło

2013-02-27 ams

Heva spojrzenie na tę odpowiedź: http: // stackoverflow.com/questions/6437828/spring-transaction-with-supports-propagation # 6437924 – GKislin

Najprostszym przykładem, o którym można pomyśleć, byłaby metoda przesyłania niektórych treści do serwera JMS. Jeśli jesteś w kontekście transakcji, chcesz, aby komunikat był powiązany z zakresem transakcji. Ale jeśli nie ma jeszcze uruchomionej transakcji, po co zawracać sobie głowę dzwonieniem do serwera transakcji i rozpoczynaniem go po prostu od jednorazowej wiadomości?

Pamiętaj, że można je zadeklarować w interfejsie API, a także w implementacji. Więc nawet jeśli nie ma dużej różnicy w twoim przypadku użycia, od umieszczenia go tam i niczego tam nie dodając, to wciąż dodaje wartość autorowi API do określenia, jakie operacje mogą być zawarte w transakcji, w przeciwieństwie do operacji, które być może nazywają zewnętrzny system, który nie uczestniczy w transakcjach.

Jest to oczywiście w kontekście JTA. Ta funkcja nie ma praktycznego zastosowania w systemie, w którym transakcje są ograniczone do fizycznie bazujących na zasobach fizycznych transakcji z bazami danych.

Źródło

2013-02-27 19:06:34 Affe

w podanym przykładzie JMS, jeśli nie ma tx, ale sesja JMS/producent jest współdzielona, to wiadomość jest wysyłana jako część TX. Domyślam się, że rozproszone tx jest jedynym miejscem, w którym SUPPORTS może być użyteczne. – ams

Myślę, że nadal może być użyteczny w ustawieniu nierozdzielonym jako znacznik interfejsu API, jeśli masz instancje NOT_SUPPORTED i chcesz je rozróżnić. Ale masz rację, że implementacja nie różni się zbytnio od dodawania niczego, jeśli tx nie są dystrybuowane. – Affe

To sprawia dobre parę wraz z readOnly=true Transakcyjnej flagą na wybranej operacji, zwłaszcza gdy jest używana ORM:

@Transactional(readOnly = true, propagation=Propagation.SUPPORTS) 
public Pojo findPojo(long pojoId) throws Exception { 
    return em.find(Pojo.class, pojoId); 
}

W takim przypadku należy upewnić się, że nie zapłacić cenę tworząc nową transakcję, jeśli istnieje nie jest już tylko do wykonania operacji wyboru.

Chociaż jeśli zostały w ten proces myślowy już można nawet rozważyć rowu transakcyjne aspekt wszyscy razem:

public Pojo findPojo(long pojoId) throws Exception { 
    return em.find(Pojo.class, pojoId); 
}

Źródło

2013-06-09 23:15:20 dimitrisli

czyli ... Czy naprawdę warto dodać adnotację @Transactional do dokonywania wyborów w lokalnej bazie danych za pośrednictwem frameworka ORM (np. MyBatis)? – aloplop85

przez "ditch the Transactional aspect", jest to to samo, co przy użyciu @NotTransactional? –

Jeśli coś nie ma aspektu transakcji lub jest @NotTransactional i jest wywoływane z poziomu transakcji, co się dzieje? na przykład jeżeli metoda transakcyjna A zapisuje coś w DB, to wywołuje metodę NotTransactional be, która również coś pisze, a następnie nakazuje A lub B rzucić niesprawdzony wyjątek, który zostanie wycofany? –

Według tego wystawia Improve performance with Propagation.SUPPORTS for readOnly operation nie należy ustawić transakcji tylko do odczytu z Propagation.SUPPORTS:

Nie ma wątpliwości, że zmiana rzeczywiście poprawi wydajność. Jest w tym wiele aspektów. Po pierwsze, połączony artykuł jest przestarzały i bardzo wadliwy, ponieważ agresywnie upraszcza sprawy. Mogę zagłębić się w szczegóły, jeśli chcesz, ale na razie to zostawię. Tutaj jest wiele rzeczy, które grają w wydajność wykonania. Bez transakcji w toku ani flaga readOnly nie jest propagowana do sterownika JDBC (co powodowałoby optymalizację wielu baz danych nie jest stosowana), ani nie zastosowałaby optymalizacji w wiosennym kodzie zarządzania zasobami JPA, jak jawne wyłączenie płukania, które - jeśli zastosowany - może znacznie poprawić wydajność w przypadku, gdy czytasz dużo danych.

Źródło

2016-04-07 13:03:09 GKislin

Kiedy używać Spring @ Transactional (propagacja = Propagacja.SUPPORTS)?

Odpowiedz

Powiązane problemy