Details
-
Bug
-
Resolution: Obsolete
-
Medium
-
None
-
4.0.7, 4.1.4, 4.2.0, 4.3.0, 4.4.0, 4.5.0alpha
-
None
Description
A timing-related scenario, hard to reproduce unless scripted, but disturbing nonetheless:
1. obj X has version 1 published
2. create versions 2 and 3, in draft mode
3. set up a workflow event that just sleeps a few secs, to make sure this can happen
4. open two browsers, and try to publish the two versions at the same time
end result:
. only one of the two versions is the finally piblished one
. BUT when looking into version history, both version 2 and 3 are marked as 'published' state
the problem is:
. the publication of both versions happens in a transaction
. in std mysql transaction isolation mode (read committed), both transactions can not see at any point in time changes that have been committed by other transactions, they always 'see' the status of the db before they initiated
. both transactions thus see the same 'current' version 1 when they start
. during their update process, they set the current version to 'archived' and the new version to 'published'
. when they commit, they do not know that somebody else has changed 'behind their back' the current version, and that they should thus update not only the field current_version in the object table, but also the field 'status' of other versions in the versions table
it is hard to fix, since
. within the transaction there is no way to know that the 'current' version has been changed by another transaction (nb: this is doable in default oracle transaction isolation level - and should be tested extensively on all supported dbs)
. within the transaction we cannot just blindly set all other pending versions to archived (they might be pending because waiting for some workflow event)
what we could do:
. either after the transaction do a select on all obj versions to check that there is no 2 versions in published state
. or do the same in a cronjob