In message <201301091744.54722.bernhard@intevation.de>
<201301091744.54722.bern hard@intevation.de>, Bernhard Reiter writes:
>Bernhard Reiter added the comment:
>Am Mittwoch, 9. Januar 2013 16:00:26 schrieb John Rouillard:
>> But the auditor *does not*
>> call a get on the database. It just uses the info passed to it in the
>> db.tx_Source string.
>
>Which I believe should be okay for doing decisions in principle, 

I agree. I think the original goal to allow the auditor to make a
decision based on the method by which an update arrived is working
fine. Now that we know why the journal anomolies are occurring I think
I am ok with saying it's not a bug in the code I wrote.

>there shouldn't be a necessity to explicitely "read" all the values
>in order to lock them when basing decisions on them.

If the auditor needs to know the current value from the database
(e.g. in moving between statuses in a workflow) then it can do the
read of the existing status and get the lock.

>> Did I understand you correctly when you indicated that doing a
>> cl.get(nodeid, 'tx_Source') in the auditor would cause parallel update
>> transactions 

If this get "solves" the journaling problem, we could always do the
get in the demo auditor for the side effect of fixing the journal
entry.