Metoda z @Transactional nie cofa zmian po wyjątku

@Transactional(rollbackOn = DataIntegrityViolationException.class)
public void saveLink(String singleLink) {
    try{
        JobOffer jobOffer = jobOfferRepository.saveAndFlush(JobOffer.builder().id(UUID.randomUUID()).build());

        JobLink jobLink = JobLink.builder()
                .jobLink(singleLink)
                .jobOffer(jobOffer)
                .isProcessed(false)
                .category("Kotlin")
                .id(UUID.randomUUID())
                .timeOfAddition(LocalDateTime.now())
                .remote(true)
                .build();

        jobLinkRepository.save(jobLink);
    } catch (Exception e){
        throw new DataIntegrityViolationException("Exception occured during saving link!");
    }

}

Mam problem taki że, w momencie gdy linia

jobLinkRepository.save(jobLink);

wyrzuci wyjątek, to następnie jest ten wyjątek łapany i przechodzimy do bloku catch. W bloku catch jest wyrzucany wyjątek kolejny.

Mam ustawione

@Transactional(rollbackOn = DataIntegrityViolationException.class)

A mimo to JPA nie robi mi rollbacku tej linii kodu.

JobOffer jobOffer = jobOfferRepository.saveAndFlush(JobOffer.builder().id(UUID.randomUUID()).build());

W efekcie czego JobOffer jest zawsze dodawany do bazy i nie ma rollbacku.

Czy mógłby ktoś mi wyjaśnić dlaczego tak się dzieje oraz pomóc? Bardzo dziękuję

Ło panie :-)
Pierwsza rzecz to kwestia kto to wywołuje - jak wygląda wywołanie, z jakiej klasy.
EDIT:
Już wiem - używasz nie tego Transactional
Używasz CDI
Użyj Springowego - też porypany, ale mniej będziesz miał pułapek (w springowym jest rollbackFor).

W przypadku projektów robionych przez kilka osób polecam dodać ArchUnit do projektu z regułą, która sprawdza, czy kod korzysta z właściwego Transactional. Na code review takie rzeczy zwykle nie są wyłapywane.

mrpawel napisał(a):

W przypadku projektów robionych przez kilka osób polecam dodać ArchUnit do projektu z regułą, która sprawdza, czy kod korzysta z właściwego Transactional. Na code review takie rzeczy zwykle nie są wyłapywane.

Pech polega na tym, że Transactional z CDI jest jak najbardziej właściwym Transactionalem. Natomiast jest pewien myk (Ale dziś magię rozwaliłem. P...), który powoduje, że może nie działać (aczkolwiek trzeba mieć dziwną konfigurację).