Umstieg von Wildfly 13->14, JPA 2.1->2.2, schreiben funktioniert nicht mehr

[JanHH]

Hallo,

habe einen seltsamen Fehler - eine JEE6 Anwendung die mit wildfly 12 und 13 (Hibernate) problemlos läuft soll nun auf modernere Versionen gesetzt werden. Ab wildfly 14 funktioniert schreiben in die Datenbank (per JPA Entity Manager) nicht mehr, es gibt aber auch keine Fehlermeldung im Log. Tabellen anlegen tut das Programm, werte hineinschreiben aber nicht - als ob sie irgendwo zwischendurch verloren gehen oder Transaktionen nicht committed werden.

Als Datenbank wird Postgres verwendet, 9.5 oder 14, JDBC-Treiber ist aktuell.

Hat da irgendjemand die zündende Idee?

Danke.

 

[LimDul]

Idee eher nein, nur ein paar Tipps wie ich vorgehen würde.

Hibernate SQL-Logging schon angeschaltet? Um zu sehen, ob die Insert/Update Statements an der DB ankommen oder gar nicht ankommen.
Hier hilft ggf. auch an passenden Stellen (am besten nach den persist Aufrufen) ein entityManager.flush() zu ergänzen, damit hibernate die aus dem Cache in DB schreibt.
Dann kann man schon mal eingrenzen ob es am Transaktionshandling oder was anderem liegt.

Ansonsten ggf. mal auf wildfly 12 oder 13 bleiben und dort auf JEE7 und dann JEE8 updaten. Wildfly 14 ist ja JEE8 only.

 

[JanHH]

"Since Java EE8 is backwards compatible with EE7, applications developed against EE7 (and earlier) will still run on WildFly 14."

(https://www.wildfly.org/news/2018/08/30/WildFly14-Final-Released/)

das mit dem logging ist hatürlich naheliegend.. man könnte ja auch mal selber drauf kommen ;-)

 

[JanHH]

Da komme ich nun tatsächlich weiter.. vielen Dank!

Wenn ich explizit entityManager.flush() aufrufe wird sql INSERT Code erzeugt und es funktioniert dann auch. Ohne flush wird immer nur SELECT Code erzeugt und es funktioniert nicht.

Aber das sagt mir jetzt genau was?

 

[KonradN]

Nur mal als einfache Idee: Kann es sein, dass beim Umstieg der FlushMode verändert wurde und der FlushModeType nun nicht mehr ALWAYS oder so ist?

Evtl. mal auf der neuen Umgebung diesen prüfen (entityManager.getFlushMode() einfach mal ins Log schreiben und schauen).

Evtl. zum Verständnis der einzelnen Modi: https://thorben-janssen.com/flushmode-in-jpa-and-hibernate/

 

[JanHH]

Hm ja. Mit wildfly 12 sagt er AUTO, mit wildfly 14 sagt er COMMIT.

 

[JanHH]

hmmm. tatsächlich, wenn ich in der persistence.xml

<property name="org.hibernate.flushMode" value="AUTO"/>

ergänze, funktioniert es. Das ist ja schonmal, toll, danke!

Aber eigentlich sollte das doch default sein!? Hm.

 

[LimDul]

Ich bin etwas verwundert, dass der Flush-Mode so viel ausmacht. Ich würde mal als nächsten Schritt mir die Transaktionsgrenzen genauer ansehen, also wo wird die Transaktion gestartet/beendet.

 

[JanHH]

ähm.. ich frag mal ganz naiv.. wie macht man das?

 

[LimDul]

An irgendwelchen Beans vermute ich mal sind @Transactional Annotationen dran. Sprich, da wird beim Eintritt in die Methode die Transaktion gestartet und beim Ende (sofern keine Exception erfolgte) das Commit durchgeführt.

Oder - dann muss ich aber passen - das Transaktionshandling war irgendwie komplett anders, was ggf. mit eine Ursache für das Problem sein kann

 

[JanHH]

Nein, das ist nicht so. Kein @Transactinal irgendwo. Generell macht die Anwendung überhaupt nichts ungewöhnliches oder irgendwie seltsames, ich bin eh nicht besonders kompetent auf dem JEE-Gebiet und kratze da vermutlich ziemlich an der Oberfläche, was die genutzten Features angeht.

Ich hab in EJBs den EntityManager

@PersistenceContext(unitName="pu")
protected EntityManager entityManager;

und dann gibts noch ein paar Servlets mit UserTransaction (utx.begin und commit)

und eine größere Ecke wo nativ SQL benutzt wird mit entityManager.createNativeQuery(), aber auch das innerhalb von EJBs ohne manuelles Transaction-Management.

Und man muss ja auch sagen - wenn man den flushMode auf AUTO stellt, wie er es bei wildfly 12 auch war und es offenbar default mässig sein sollte, funktioniert ja auch alles. Vermutlich ist einfach alles ok.

Bleibt nur das Rätsel warum flushMode hier defaultmässig COMMIT ist.