Bug 154871 - Java code handles transactions incorrectly
Java code handles transactions incorrectly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Other (Show other bugs)
RHN Devel
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Robin Norwood
:
Depends On:
Blocks: 151514
  Show dependency treegraph
 
Reported: 2005-04-14 13:00 EDT by David Lutterkort
Modified: 2013-04-30 19:39 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHN 4.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-31 16:56:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lutterkort 2005-04-14 13:00:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040204 Galeon/1.3.12

Description of problem:
The Java code does not always ensure that we have exactly one transaction per HTTP request. In some cases we commit more than once during a request, making it possible to leave objects in an inconsistent state that the user has no way of fixing.

UserManager.createUser is an example of this.

See the thread at http://post-office.corp.redhat.com/archives/rhn-java-list/2005-April/msg00169.html for more discussion





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


How reproducible:
Always

Steps to Reproduce:
Review code
  

Additional info:
Comment 1 David Lutterkort 2005-04-27 14:23:19 EDT
Committed a TransactionFactory at r53746
Comment 2 David Lutterkort 2005-04-27 14:24:42 EDT
Fixed estimate and updated with progress
Comment 3 David Lutterkort 2005-05-09 15:38:27 EDT
Txn handling is now done in SessionFilter. Nesting txns will produce errors. r54527
Comment 4 David Lutterkort 2005-05-09 15:45:44 EDT
Update effort info
Comment 5 Todd Warner 2005-05-16 13:59:47 EDT
mass move to ON_QA
Comment 6 Vlady Zlatkin 2005-06-27 20:57:29 EDT
testplan?
Comment 7 David Lutterkort 2005-07-06 16:46:19 EDT
This bug is not testable by QA. The only indication that something go wrong is
that if a user performs a UI action that changes something, and that action
fails with a server error, changes may have been written to teh database.

We have unit tests to verify that this does not happen;

Bret: what's the best proper way to close out this bug ?
Comment 8 Bret McMillan 2005-07-14 16:09:19 EDT
mass move for 7/14 qa push.  picking up jesusr's and shughes' since they're both
out, as well.
Comment 9 Bret McMillan 2005-07-25 21:15:20 EDT
Setting rnorwood as qa contact for java migration bugs
Comment 10 Robin Norwood 2005-07-26 12:07:04 EDT
Moving this to PROD_READY, since as david says, there's not a good way to QA
this directly.

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