This issue is split out from issue2550731 (Add mechanism for the detectors to be 
able to tell the source of the data changes) where it was detected.

The symptoms are:
When using a database that allow parallel access. Using an auditor that sets an 
attribute to different values (and delays some time) to show the effect with a 
higher  chance. If then two requests come in quickly, the attribute value of the first 
request is lost from the history record. Thus it is lost at all, which is data loss of 
possible user input and this not happen.

Expected behaviour:
The requests are serialised somehow and all attribute values make it into the 
history.

First observations:
Ralf expected the database transaction mechanism to work here and prevent the 
trouble. Issue2550731 seems to prove that this does not work, at least not with 
Postgresql. 

Next steps:
Ralf said, he wanted to peek into this (msg4739) as he has some experience with 
database transactions. (So I took the liberty to assign it to Ralf.)

It probably makes sense to:
a) Simply the test case to be reproduced without the source detection with 
current roundup mainline. And to be triggered with as little code as possible. Best 
would be a test function that we can use for automatic testing as well.
b) Try the problem with other databases that have parallel access like MariaDB, 
to rule out a PostgreSQL specific problem.