Uploaded image for project: 'Application Server 7'
  1. Application Server 7
  2. AS7-4552

JBoss AS 7 produces non-transactional (autocommit) EntityManager within transactional EJB methods when using 3rd party javax.sql.DataSource via @DataSourceDefinition


    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 7.1.1.Final
    • Fix Version/s: 7.1.2.Final (EAP)
    • Environment:


      When using a javax.sql.DataSource via @DataSourceDefinition to create the JTA datasource for a persistence unit, transactional EJB business methods run without transactions. No warning or error is emitted.

      Business method calls annotated @TransactionAttribute(TransactionAttributeType.REQUIRED) receive an EntityManager that is in autocommit mode, ie is not in a transaction.

      This violates the EJB3 spec and is a nasty problem.

      I discovered this when testing some code against PostgreSQL that uses deferred constraints to create two interdependent database objects; record A must have at least one record B referencing it, but record B also has a foreign key reference to record A. This can be satisfied only with deferred constraints, and works fine in SQL-level testing. When testing with Arquillian at the JBoss AS 7 / Hibernate / JPA level, though, it was breaking.

      Further investigation showed that the entity manager was in autocommit despite the method being transactional, as demonstrated by a test that tries to create and fetch from a cursor.

      I've now verified that the issue exists when using PostgreSQL or H2 as the database, so it's not specific to PostgreSQL. I've attached test cases for both databases.

      JBoss AS 7 clearly has some validation and checking to do because it must not allow an autocommit entity manager to be injected for transactional business methods. That's a really critical error, as it effectively means that transaction isolation is always at DIRTY_READ (which most DBs don't even support) rather than the requested level, and it's impossible to roll back work!

      As a workaround, it should be possible to deploy an archive with an embedded jboss-ds.xml instead of using @DataSourceDefinition . I haven't tested this - struggling to find documentation on in-archive deployment of jboss-ds.xml or equivalent jboss-specific descriptor like a datasource definition for jboss-web.xml .

      Using the jboss admin cli, or deploying a jboss datasource definition xml file to the deployments folder separately to the program archive, isn't subject to the problem. That's a PITA when unit testing, though.

        Gliffy Diagrams




              • Assignee:
                swd847 Stuart Douglas
                ringerc Craig Ringer
              • Votes:
                2 Vote for this issue
                10 Start watching this issue


                • Created: