# JPA / EJB Transaktion



## beta20 (26. Mrz 2016)

Hallo zusammen, 

ich habe eine Delete - Methode. Vor dem Löschen des "Jobs" sollen davor erst noch die Berechtigungen gelöscht werden. 
Nun kann es aber  ja sein, dass irgendwas schief läuft beim Löschen des Jobs (die letzten 2 Zeilen). Dann sind aber die Berechtigungen zuvor schon gelöscht worden.

Wie kann ich das schaffen, dass die Berechtigungen auch nur gelöscht werden, wenn alles "successful" war? Also irgendwie ein Rollback der zuvor gelöschten Berechtigungen quasi?


```
public void deleteJob(Job job) throws JobNotFoundException,
            JobCurrentlyActiveException {

        if (job == null) {
            throw new JobNotFoundException("This Job with doesn¬¥t exist");
        }

        // Permissions davor löschen
        try {
            List<Permission> permissionList = permissionService
                    .findAllPermissionByJob(job.getId());

            for (Permission p : permissionList) {
                entityManager.remove(p);
            }
        } catch (Exception e) {

        }

        // Derzeitige Job kann nicht gelöscht werden
        try {
            ApplicationInfo applicationInfo = applicationInfoService
                    .findApplicationInfoByCurrentIndicator();
            if (applicationInfo.getCurrentJob().equals(job)) {
                throw new JobCurrentlyActiveException(
                        "Der derzeitige Job kann nicht gelöscht werden");
            }
        } catch (ApplicationInfoNotFoundException e) {

        }

        Job managedJob = entityManager.find(Job.class, job.getId());
        entityManager.remove(managedJob);
    }
```


----------



## Saheeda (8. Apr 2016)

Dafür gibts die Annotation @Transactional.

http://blog.jhades.org/how-does-spring-transactional-really-work/


----------



## stg (8. Apr 2016)

@Saheeda Ich sehe nichts, was darauf hindeutet, dass der TE Spring verwendet. Da dort auch noch "EJB" im Titel auftaucht, spricht für mich auch eher dagegen.

Aber der intent ist natürlich der richtige. Es sollte einfach alles in einer Transaktion gemacht werden, wie auch immer das dann auch tatsächlich gemacht wird. EJB Session Beans sind auch von Haus aus per default "transactional". Ich sehe hier eigentlich nur Probleme beim Exception handling. Da sollte der TE sich mal anschauen, wie das Im Java EE Umfeld ausschaut und diesbezüglch mal z.B. das Oracle JEE Tutorial durcharbeiten.


----------



## Saheeda (10. Apr 2016)

@stg 
Ups, mein Fehler. Ich habe JPA bisher nur im Spring-Kontext verwendet bzw. gesehen, deswegen gehörte das für mich irgendwie automatisch zusammen.


----------



## beta20 (26. Apr 2016)

stg hat gesagt.:


> @Saheeda Ich sehe hier eigentlich nur Probleme beim Exception handling.


was genau meinst du damit?


----------



## mrBrown (26. Apr 2016)

Du hast leere catch-Blöcke, die da sicher nicht vorkommen sollten


----------



## stg (27. Apr 2016)

Das auch, ja, aber ich spielte damit eigentlich eher auf den Unterschied zwischen System Exceptions und App Exceptions an.

Vereinfacht und auf das Beispiel hier bezogen:
Wenn beim Löschen des Jobs ein Fehler auftritt, so wird vom Framework eine EJBException geworfen. Diese wird "nach oben" weitergereicht, zunächst bis zum Startpunkt der Transaktion. Dort soll nun eigentlich die Transaktion commited werden. Liegt aber eine EJBException vor, so führt der EJB Container ein Rollback durch. Im Client, der die Methode aufgerufen hat, kannst du nun "sicher" die Exception fangen und entsprechend darauf reagieren. Fängst du aber eine solche Exception schon vorher auf dem Weg von Hand ab, so verwehrst du dem Container die Möglichkeit ein Rollback durchzuführne, denn aus seiner Sicht lief alles ohne Fehler ab und die Transaktion wird commited.


----------

