11:57 p.m.
[
https://issues.jboss.org/browse/AS7-4552?page=com.atlassian.jira.plugin.s...
]
Craig Ringer commented on AS7-4552:
-----------------------------------
Stuart: Thanks for the clarification.
Doing a bit of reading, @DataSourceDefinition appears to be specified in JSR250 section
2.13. It explicitly names the allowable interfaces the specified class must implement, and
doesn't accept java.sql.Driver. Blast; that would've been a nice option to have.
This clause of JSR250 really helps suggest a resolution to this issue:
{quote}
Vendors are not required to support properties that do not normally apply to a
specific data source type. For example, specifying the transactional property to
be true but supplying a value for className that implements a data source class
other than XADataSource may not be supported.
{quote}
The above permits JBoss AS 7 to simply refuse to deploy projects using
@DataSourceDefinition without transactional=false with a non-XA datasource, or at least to
warn about them loudly and refuse to use them with transactional EJB methods. That might
be a good idea, to make devs be explicit via transactional=false and (for EJBs) a
@TransactionAttribute of NEVER, NOT_SUPPORTED, or (maybe?) SUPPORTED.
I guess the question then has to be "what's the principle of least
surprise?". What'll cause the lowest rate of unintended behavior,
misunderstanding, and failure in code using the feature? Possibilities that come to mind
for me include some combination of:
(1) Loud angry warnings in the logs that @DataSourceDefinition is unsafe without an
additional property specifying the JDBC driver, and that a -ds.xml should be preferred
(with URL to article).
(2) Simply failing a deployment that uses @DataSourceDefinition with a warning like the
above unless transactional=false is specified. Throw if transactional EJB methods are
entered with a non-transactional data source. Appears to be spec-legal and may be safest.
(3) Reworking the JTA / pool / DS interaction to accomodate externally-provided
javax.sql.DataSource implementations or XA data sources. Probably must be combined with
(2).
(4) ... ?
IMO at minimum it should be a deployment error to specify
@DataSourceDefinition(class=some.javax.sql.DataSource, transactional=true) ;
transactional=true should only be legal with an XA datasource unless AS7 can cache the
connections and take care of the transaction management from the regular DataSource its
self.
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