Bug 822240 - Embedded container loses transaction when using JDBC connection with CMTs
Embedded container loses transaction when using JDBC connection with CMTs
Status: NEW
Product: RHQ Project
Classification: Other
Component: Tests (Show other bugs)
Unspecified Unspecified
medium Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2012-05-16 15:19 EDT by John Sanda
Modified: 2012-05-21 11:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test that reproduces the issue (2.02 KB, text/x-java)
2012-05-16 15:24 EDT, John Sanda
no flags Details

  None (edit)
Description John Sanda 2012-05-16 15:19:24 EDT
Description of problem:
I have been a writing a test for metrics to verify that data is written into the raw tables. The test passes. No exceptions are thrown, yet nothing is written into the raw tables. I stripped my test down to be as simple as possible where I create a simple measurement report with a single numeric data point and invoke MeasurementDataManagerBean.mergeMeasurementReport. The data is not written to the raw tables.

Jay Shaughnessy and I both investigated this and observed the same thing after a good bit of testing. If multiple calls in the test are made to insert data, it appears all but the first are persisted in the database. 

For numeric data, mergeMeasurementReport just delegates to MeasurementDataManagerBean.addNumericData which has a transaction attribute type of REQUIRES_NEW. We still observe the issue if directly calling addNumericData instead of mergeMeasurementReport.

I am of the opinion that this is a problem with the EJB container and/or transaction service in the embedded container we use for testing. I have not yet been able to reproduce this against my development RHQ server. Since it is harder to test against a live server, we may want to do further testing to be more certain that the issue is in fact limited to the embedded container.

The work around seems to be easy enough where this is a problem. For MeausrementDataManagerBean.addNumericData and any other places where this might happen, just make an initial call with some dummy data.

Even with a work around, this issue calls into question the reliability of some of our testing infrastructure and should make us take a hard look at upgrading our technology stack sooner rather than later. As far as I know, the embedded container we use for testing has been an abandoned project for some time. There is no upgrade path for it. Arquillian does not not support AS 4.2.3; so, it is not a viable alternative right now.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 John Sanda 2012-05-16 15:24:59 EDT
Created attachment 585042 [details]
Test that reproduces the issue

Drop this test in the server/jar module under src/test/java and run as follows,

$ mvn test -Dtest=MetricsTest

Inspect the appropriate raw table and you will observe that the data is not there.
Comment 2 Jay Shaughnessy 2012-05-16 15:38:19 EDT
Just to confirm, after nearly a day of trying various combinations I could
not get around,or explain, this strange behavior.  The first call to
addNumericData does not commit the data written to the raw data table. The
processing all works, the Connection is valid and autoCommit is off at the
time the SLSB method exists.  All subsequent calls succeed.

It does not seem to have anything to do with the particulars of the call as
I stripped out almost everything in my testing.  The dummy data workaround
works, but note that you must actually send in data and manipulate the db.

It just seems like the first call gets rolled back instead of committed. Does
not make a lot of sense.
Comment 3 Mike Foley 2012-05-21 11:52:04 EDT
per BZ triage 5/21/2012 (asantos, loleary, ccrouch, mfoley)

Note You need to log in before you can comment on or make changes to this bug.