0003799: Race condition in summary calculations causes inconsistent totals

View Issue Details [ Jump to Notes ] [ Wiki ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0003799

mantisbt

bugtracker

public

2004-04-30 13:56

2008-08-12 09:36

Reporter

dfaught

Assigned To

grangeway

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

won't fix

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0003799: Race condition in summary calculations causes inconsistent totals

Description

The Summary page has a race condition - if a new bug is filed while the numbers are being calculated, part of the page might account for the new bug and part of it might not.

I was running a stress test that was filing new bugs in rapid succession. Frequently when I loaded the Summary page during this test, the total bugs shown in the "By Status" section did not match the total in the "By Severity" section.

Perhaps it's not a huge problem if the totals don't match exactly, but users might distrust all the data in the reports if they're not internally consistent.

Additional Information

I'll post the Perl script I used to stress test the server. You'll have to customize it for your configuration if you want to use it.

Tags

No tags attached.

Attached Files

outofsync.pdf [^] (28,961 bytes) 2004-04-30 14:05

mtest [^] (1,262 bytes) 2004-04-30 14:06

Relationships

Notes
(0005467) Apel (reporter) 2004-05-04 05:31	This is really a fundamental design issue. You'd have to lock all the tables you are about to query before running the queries but this still would not guarantee fully consistent data as mantis does not use atomic transactions. So when issuing the lock a (non-atomic) transaction might have updated one table already while another update is still pending.

(0018444) grangeway (developer) 2008-07-13 13:06	The summary page executes a number of queries to pull each bit of data - without locking the whole database down for 2 seconds (affecting other users), there's not really a sensible way to fix this. For the most part, it's a summary of an instant in time - we know that 2 minutes later a new bug might come into the system, so I think it needs to be treated as a dynamic temporary data. Paul

Issue History
Date Modified	Username	Field	Change
2004-04-30 13:56	dfaught	New Issue
2004-04-30 14:05	dfaught	File Added: outofsync.pdf
2004-04-30 14:06	dfaught	File Added: mtest
2004-05-04 05:31	Apel	Note Added: 0005467
2008-07-13 13:06	grangeway	Note Added: 0018444
2008-07-13 13:06	grangeway	Status	@0@ => resolved
2008-07-13 13:06	grangeway	Resolution	@0@ => won't fix
2008-07-13 13:06	grangeway	Assigned To	=> grangeway
2008-08-12 09:36	grangeway	Status	resolved => closed

MantisBT 1.2.2 git master-1.2.x[^]

Time: 0.2120 seconds.
memory usage: 1,943 KB