[
https://issues.jboss.org/browse/AS7-4552?page=com.atlassian.jira.plugin.s...
]
henk de boer commented on AS7-4552:
-----------------------------------
From what I've seen in this discussion and my (poor) understanding
of the code in question, the -ds.xml mechanism can't just be changed to use a
javax.sql.DataSource, as it expects to do its own connection management, pooling, etc.
I would have to inspect the code, but I wonder it that's the case. If I'm not
mistaken (and my JDBC knowledge is admittedly a bit rusty), a plain
{{javax.sql.DataSource}} that's provided by the DB vendor is a direct alternative for
{{java.sql.Driver}}. In fact, it's the more modern and preferable version. Such
DataSource shouldn't do much if any connection management and certainly shouldn't
do any pooling.
This DataSource typically calls the DriverManager ({{java.sql.DriverManager}}), which on
its turn calls the {{Driver.connect}} method. {{java.sql.Driver#connect}} can take extra
properties, but apart from "user" and "password" these are DB
specific. The DataSource implementation can be configured with the same kind of DB
specific properties.
So, _in my understanding_, the differences between {{java.sql.Driver}} and
{{javax.sql.DataSource}} are rather small and they eventually end up at the same point.
Also, for XA, {{-ds.xml}} does require a {{javax.sql.XADataSource}}, not a
{{java.sql.Driver}}. Other AS implementations, like GlassFish, do all their magic with a
{{javax.sql.DataSource}} (or XA variant) instead of a Driver.
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: Scott Marlow
Labels: autocommit, ejb, h2, h2sql, jdbc, jta, postgresql, transaction,
transaction_manager, xa
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