> The patch file for roundup is on the the issue already and the
> additional detector change and the problem I see is described at:
> 
>   http://sourceforge.net/mailarchive/message.php?msg_id=29359236

Is it correct that your detector is an auditor and no reactor?

I think I know why you're seeing that behaviour:
you are not looking at the old title, that means the database system is
free to set the title to the title set by one of the parallel
transactions it chooses as the "winner". This is the one you're seeing in
the history for all the other transactions.

Some of the title updates will never make it to the database. All of your
parallel transactions will get the same old value of the title.

Only the value present in the title at the start of the current
transaction is later logged to the history. This is the same for all the
transactions started at the same time.

Since your updates to the title are not based on any values in the
database, your transactions are trivially serializable (the db may just
chose one of the transactions which it declares the last writer and
ignore all the others).

Sometimes serialisation of database actions are not very intuitive :-)

To get the correct behaviour you'll have to tell the DB that you are
modifying the title based on the previous one. This means in the auditor
you should first get the old title with

t = db.issue.get (nodeid, 'title')

then rewrite it as indicated in the message given above.

This *will* probably produce tracebacks indicating concurrency problems.

That said: Testing your new mechanism via history logs is probably not
the way to go if you additionally want to do this in parallel because the
history reflects only the title at the start of the transaction and some
titles will never make it to the history.

It is probably still ok to draft a (non-concurrent) regression test that
updates the title with the value passed and checks that it is updated
correctly.

As you noted: The messages printed indicate the correct value.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com