[jboss-jira] [JBoss JIRA] (AS7-4552) JBoss AS 7 produces non-transactional (autocommit) EntityManager within transactional EJB methods when using 3rd party javax.sql.DataSource via @DataSourceDefinition

Thu Jun 28 18:23:14 EDT 2012

    [ https://issues.jboss.org/browse/AS7-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703843#comment-12703843 ] 

henk de boer commented on AS7-4552:
-----------------------------------

For reference, I tested the problematic application I reported at https://community.jboss.org/message/731260 on JBoss EAP 6.0.0 and it seems to work nearly perfectly now.

A tiny small problem is that with the combination of en embedded h2 and an auto-created schema by Hibernate, the DB seems to be closed a bit too when shutting down JBoss. When Hibernate tries to drop the schema, the following exception is thrown:

{noformat}
org.h2.jdbc.JdbcSQLException: Database is already closed (to disable automatic closing at VM shutdown, add ";DB_CLOSE_ON_EXIT=FALSE" to the db URL) [90121-161]
        at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
        at org.h2.message.DbException.get(DbException.java:169)
        at org.h2.message.DbException.get(DbException.java:146)
        at org.h2.message.DbException.get(DbException.java:135)
        at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1394)
        at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.checkClosed(JdbcXAConnection.java:475)
        at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1369)
        at org.h2.jdbc.JdbcConnection.createStatement(JdbcConnection.java:191)
        at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:304)
        at org.hibernate.tool.hbm2ddl.DatabaseExporter.<init>(DatabaseExporter.java:54)
        at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:367)
        at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:318)
        at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:314)
        at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1446)
        at org.hibernate.ejb.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:194)
        at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.stop(PersistenceUnitServiceImpl.java:98)
        at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
        at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:732)
{noformat}

But this is really minor. Overall, a REALLY great job done by the JBoss team!

{quote}
any differences between @DataSourceDefinition and a -ds.xml remaining? If so I'm happy to write up suitable docs, just need to know the gist of what needs to be covered.
{quote}

I'm curious about that as well. https://community.jboss.org/wiki/DataSourceConfigurationInAS7 now still mentions @DataSourceDefinition is recommended only for development and testing purposes. Is that still true?

> JBoss AS 7 produces non-transactional (autocommit) EntityManager within transactional EJB methods when using 3rd party javax.sql.DataSource via @DataSourceDefinition
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4552
>                 URL: https://issues.jboss.org/browse/AS7-4552
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB, JPA / Hibernate, Transactions
>    Affects Versions: 7.1.1.Final
>         Environment: java version "1.7.0_01"
> Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
> Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
> Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Craig Ringer
>            Assignee: Stuart Douglas
>              Labels: autocommit, ejb, h2, h2sql, jdbc, jta, postgresql, transaction, transaction_manager, xa
>             Fix For: 7.1.2.Final (EAP)
>
>         Attachments: h2-test-logs.zip, JBossAS7ContainerTransactionsWith3rdPtyDataSource.zip, JBossAS7ContainerTransactionsWith3rdPtyDataSourceFixed.zip, JBossAS7ContainerTransactionsWithJBossDataSource.zip, JBossAS7H2Tests.zip
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira