Bug 154871

Summary:	Java code handles transactions incorrectly
Product:	[Retired] Red Hat Network	Reporter:	David Lutterkort <lutter>
Component:	RHN/Other	Assignee:	Bret McMillan <bretm>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Robin Norwood <robin.norwood>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	RHN Devel	CC:	hbrock, rhn-bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHN 4.0.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-08-31 20:56:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	151514

Description David Lutterkort 2005-04-14 17:00:29 UTC

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 18:23:19 UTC

Committed a TransactionFactory at r53746

Comment 2 David Lutterkort 2005-04-27 18:24:42 UTC

Fixed estimate and updated with progress

Comment 3 David Lutterkort 2005-05-09 19:38:27 UTC

Txn handling is now done in SessionFilter. Nesting txns will produce errors. r54527

Comment 4 David Lutterkort 2005-05-09 19:45:44 UTC

Update effort info

Comment 5 Todd Warner 2005-05-16 17:59:47 UTC

mass move to ON_QA

Comment 6 Vlady Zlatkin 2005-06-28 00:57:29 UTC

testplan?

Comment 7 David Lutterkort 2005-07-06 20:46:19 UTC

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 20:09:19 UTC

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-26 01:15:20 UTC

Setting rnorwood as qa contact for java migration bugs

Comment 10 Robin Norwood 2005-07-26 16:07:04 UTC

Moving this to PROD_READY, since as david says, there's not a good way to QA
this directly.