0

I have a problem with a CDI Named Bean which is @Transactional.

I use the WildFly 11.1.0.Final.

Here the Code: https://gist.github.com/stefanwendelmann/7a1f8352900067d5a59826d6ee205044

This is the persistence.xml

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
             xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
             http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="QuoLoco" transaction-type="JTA">
    <description>Verbindung zur QuoLoco Datenbank</description>
    <jta-data-source>java:/QUOLOCO_NORM</jta-data-source>
    <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
    <properties>
      <property name="hibernate.format_sql" value="false"/>
      <property name="hibernate.dialect" value="org.hibernate.dialect.SQLServerDialect"/>
      <property name="hibernate.id.new_generator_mappings" value="false"/>
    </properties>
  </persistence-unit>
</persistence>

When I call the method "doChange" and only edited Empfangseinheittypenparameter, the em.remove and em.persist doesn't trigger a flush.

When I call the method "doChange" and edited some of the main  Empfangseinheittypen empfangseinheittyp, I make a find on the Empfangseinheittypenparameter don't need a flush

What am a doing wrong?

Both methods are public.

Please see a picture of the Application attached

Thanks in advance for your help

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Stefan Höltker
  • 311
  • 5
  • 21
  • If this is relevant yet. I did some tests with CDI-Transactional. There are no significant differences to EJB. Therefore a few questions: How did you find out, that the changes did not get flushed? What DBMS are you using? Did you call doChange in a subclass or from another bean? – aschoerk Dec 01 '17 at 04:31
  • Hi @aschoerk we use a SQL Server 2008 R2. The call comes from the xhtml JSF frontend. Now we changed to BMT to go along with our application. – Stefan Höltker Dec 19 '17 at 11:14
  • Ahh SqlServer 2008, so no MVCC. But: How did you find out, that the changes did not get flushed? Did you call doChange in a subclass or from another bean? – aschoerk Dec 19 '17 at 16:18
  • No the doChange was called from the same bean. It (empfangseinheittypenparameter) got flushed when we edited some of the main infos (Empfangseinheittypen) – Stefan Höltker Dec 21 '17 at 13:57
  • "called from the same bean" normally means, that the transactioninterceptor is not working. Are you sure, that it does? – aschoerk Dec 21 '17 at 18:14

1 Answers1

1

According to the comments, doChange is called from the same bean. The problem is similar to @Transactional method called from another method doesn't obtain a transaction which means, that the transaction will not end with doChange, so you can not expect a flush to be done when returning from the method.

aschoerk
  • 3,333
  • 2
  • 15
  • 29