Hi Ralf,
thanks for looking into this issue. I don't have much experience in this part
of roundup's code, so your input is highly appreciated. I am just trying
John to get this resolved. 

A few thoughts (thought I know I have not understood everything):
To me it does not make sense what I have seen and what you - Ralf - describe
how it should work. John gave me a test case and the behaviour is surprising
and unwanted as far as I can say. Even with my ideas of a transaction.
John gave me a test case with tx_Source being an attribute to msg and 
issue which is manipulated by an auditor. 
John, please publish this testcase or an improved one.

When running with postgresql, the problem is that the history is not set
to the right value. Yes, I would expect a locking mechanism in the database
to prevent this, a transaction would be cool. However it does not prevent it.
Maybe that is the result of line 2996 of rdbms_common.py:
   oldvalues = copy.deepcopy(self.db.getnode(self.classname, itemid))

The msql prevention of the same id on new nodes is probably something 
unrelated. (I've only mentioned it because it made me think why postgresql does 
not have such special code.)

I've not fully grasped how the journal should work, so I'm unsure about
what should be saved, however there is special code for other types than
String that will save the new values.

If we do have a transaction thing already going on and the behaviour is 
explainable then it is underdocumented, because it would mean special 
requirements for auditors.
  





  

The problem is that the code of set_inner()