AbstractTransactionalTestNGSpringContextTests not working as expected when an EJB with TransactionAttribute.REQUIRES_NEW is encountered [SPR-6132]

[spring-projects-issues]

Ed Randall opened SPR-6132 and commented

When an @Test method executes an EJB annotated with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW), it seems that the test transaction is consumed when the REQUIRES_NEW transaction completes. Subsequent transaction behavior then becomes unexpected.

---

Affects: 3.0.5

Reference URL: http://forum.springsource.org/showthread.php?p=261074

Attachments:

• requiresnew.zip (4.15 kB)

Issue Links:

• No bean of type ConfigurableEnvironment in AbstractTestNGSpringContextTests [SPR-14834] #19400 No bean of type ConfigurableEnvironment in AbstractTestNGSpringContextTests
• ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext [SPR-12918] #17517 ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext
• Improve documentation of transactional support in the TestContext framework [SPR-11399] #16026 Improve documentation of transactional support in the TestContext framework
• Include TestContext in log message when starting a new transaction in TransactionalTestExecutionListener [SPR-11323] #15947 Include TestContext in log message when starting a new transaction in TransactionalTestExecutionListener
• Support timed transactional TestNG tests in the TestContext framework [SPR-6124] #10792 Support timed transactional TestNG tests in the TestContext framework

Referenced from: commits 8105011, e20c927, c0eafa9

15 votes, 9 watchers

[spring-projects-issues]

Ed Randall commented

Standalone TestNG/JPA/EJB test case to demonstrate this problem.

[spring-projects-issues]

Ian Jones commented

I think I have hit this problem developing an application using spring. I have a scenario where a table is created and then updated with multiple rows. I am using EJB with Spring transactions (@Transactional) and my (POJO) DAO's create method is marked as @Transactional(propagation=Propagation.REQUIRES_NEW). This correctly suspends the current transaction, creates the table and returns but the calling method which then performs the insert is no longer covered by a transaction and so the updates cannot be subsequently rolled back if required.

I can provide a simple(ish) test case consisting of two EJBs and requiring a single datasource but I think it is a pretty good match for this issue.

[spring-projects-issues]

Sam Brannen commented

Hi guys,

Please create a self-contained project which reproduces the issue you are encountering and then add a link to that project here (in the form of a comment) once you've created it and submitted. Doing so will improve the chance of this issue getting addressed.

You'll find details on how to do this in the README for the spring-framework-issues repository on GitHub.

Thanks,

Sam

[spring-projects-issues]

Ed Randall commented

I already attached a project which reproduces this, way back in Sept 09.
This and #10792 have just been endlessly deferred back since then.

[spring-projects-issues]

Sam Brannen commented

Please note that I have added the pull-request-encouraged label to this issue in order to denote that contributions from the community would be very welcome, both in the form of an up-to-date reproduction of the issue in GitHub against Spring Framework 3.2.x as well as a pull request containing a solution to the issue.

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

Hi Ed,

I fully understand your frustration; however, both this issue and #10792 have only received two votes from the community. Thus, with the limited amount of time that I have to devote to Spring, having GitHub projects that I can simply check out and run would greatly increase the chance that I can address such issues. Otherwise I have to devote my time to issues with higher priority.

Regards,

Sam

[spring-projects-issues]

Xavier Detant commented

Added a pull request on github : spring-attic/spring-framework-issues#55

[spring-projects-issues]

Sam Brannen commented

Resolving this issue as "Works as Designed".

See the explanation provided in the comments for GitHub commit c0eafa9:

Introduce EJB-based transactional tests in the TCF

This commit introduces transactional integration tests executing
against both JUnit and TestNG in the TestContext framework (TCF) using
@TransactionAttribute in EJBs instead of Spring’s @Transactional
annotation.

These tests disprove the claims raised in #10800 by demonstrating that
transaction support in the TCF works as expected when a transactional
EJB method that is configured with TransactionAttribute.REQUIRES_NEW is
invoked. Specifically:

• The transaction managed by the TCF is suspended while such an EJB method is invoked.
• Any work performed within the new transaction for the EJB method is committed after the method invocation completes.
• The transaction managed by the TCF is resumed and subsequently either rolled back or committed as necessary based on the configuration of @Rollback and @TransactionConfiguration.

The configuration for the JUnit-based tests is straightforward and self
explanatory; however, the configuration for the TestNG tests is less
intuitive.

In order for the TCF to function properly, the developer must ensure
that test methods within a given TestNG test (whether defined locally,
in a superclass, or somewhere else in the suite) are executed in the
proper order. In a stand-alone test class this is straightforward;
however, in a test class hierarchy (or test suite) with dependent
methods, it is necessary to configure TestNG so that all methods within
an individual test are executed in isolation from test methods in other
tests. This can be achieved by configuring a test class to run in its
own uniquely identified suite (e.g., by annotating each concrete
TestNG-based test class with @Test(suiteName = "< Some Unique Suite
Name >")).

For example, without specifying a unique suite name for the TestNG
tests introduced in this commit, test methods will be executed in the
following (incorrect) order:

• CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
• CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
• RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
• RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
• CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()

The reason for this ordering is that test2IncrementCount1() depends on
test1InitialState(); however, the intention of the developer is that
the tests for an individual test class are independent of those in
other test classes. So by specifying unique suite names for each test
class, the following (correct) ordering is achieved:

• RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
• RollbackForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
• RollbackForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
• CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
• CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
• CommitForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
• RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
• RollbackForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
• RollbackForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
• CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
• CommitForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
• CommitForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()

See the JIRA issue for more detailed log output.

Furthermore, @DirtiesContext(classMode = ClassMode.AFTER_CLASS) has
been used in both the JUnit and TestNG tests introduced in this commit
in order to ensure that the in-memory database is reinitialized between
each test class.

[spring-projects-issues]

Sam Brannen commented

Here is the detailed log output mentioned in the above comments.

Before Suite Configuration

Began transaction (1)   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (1)   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (1)   for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (1)   for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test1InitialState@RollbackForRequiredEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test1InitialState@RollbackForRequiredEjbTxDaoTestNGTests
Began transaction (2)   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests

After Suite Configuration

Began transaction (1)   for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (2)   for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests
Began transaction (3)   for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiresNewEjbTxDaoTestNGTests, testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTests

Began transaction (1)   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (2)   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests
Began transaction (3)   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiredEjbTxDaoTestNGTests,      testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTests

Began transaction (1)   for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test1InitialState@RollbackForRequiredEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test1InitialState@RollbackForRequiredEjbTxDaoTestNGTests
Began transaction (2)   for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test2IncrementCount1@RollbackForRequiredEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test2IncrementCount1@RollbackForRequiredEjbTxDaoTestNGTests
Began transaction (3)   for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test3IncrementCount2@RollbackForRequiredEjbTxDaoTestNGTests
Rolled back transaction for ... RollbackForRequiredEjbTxDaoTestNGTests,    testMethod = test3IncrementCount2@RollbackForRequiredEjbTxDaoTestNGTests

Began transaction (1)   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test1InitialState@AbstractEjbTxDaoTestNGTests
Began transaction (2)   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test2IncrementCount1@AbstractEjbTxDaoTestNGTest
Began transaction (3)   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTests
Committed transaction   for ... CommitForRequiresNewEjbTxDaoTestNGTests,   testMethod = test3IncrementCount2@AbstractEjbTxDaoTestNGTest

[spring-projects-issues]

Sam Brannen commented

Further information on method invocation ordering can also be found in the official TestNG Manual.

Here is an excerpt from section 5.7.1 - Dependencies with annotations:

By default, dependent methods are grouped by class. For example, if method b() depends on method a() and you have several instances of the class that contains these methods (because of a factory or a data provider), then the invocation order will be as follows:

• a(1)
• a(2)
• b(2)
• b(2)

TestNG will not run b() until all the instances have invoked their a() method.

This behavior might not be desirable in certain scenarios, such as for example testing a sign in and sign out of a web browser for various countries. In such a case, you would like the following ordering:

• signIn("us")
• signOut("us")
• signIn("uk")
• signOut("uk")

For this ordering, you can use the XML attribute group-by-instances. This attribute is valid either on <suite> or <test>:

<suite name="Factory" order-by-instances="true">

or

<test name="Factory" order-by-instances="true">

As mentioned in the GitHub commit comments, grouping dependent methods by instance can also be achieved directly within the code by specifying a suite name at the class level. For example:

@Test(suiteName = "Commit for REQUIRED")
@ContextConfiguration("/org/springframework/test/context/transaction/ejb/required-tx-config.xml")
@TransactionConfiguration(defaultRollback = false)
public class CommitForRequiredEjbTxDaoTestNGTests extends AbstractEjbTxDaoTestNGTests {

	/* test methods in superclass */

}