Wt

With Wt 3.3.5-rc2, a call to QueryModel setData() emits the dataChanged signal, as expected. However, the dataChanged signal occurs prior to the transaction commit for the underlying database. As a result, the updated data is not visible to a second Dbo session at the time a dataChanged signal is emitted.

In practice, this can cause a race condition if the dataChanged signal is being used to post to a second Wt session advising it to refresh stale data. That is, the second Wt session has the potential to react to the post (resulting from dataChanged) before the call to setData in the first session has committed the transaction and thus the second session can see stale data. The likelihood of encountering this race condition is likely to be system specific.

The setItemData convenience method works in a different way and only emits dataChanged after a transaction is committed. So, setItemData seems like a reasonable workaround for this issue.

A unit test that demonstrates this issue by using two Dbo sessions is attached. The setItemData check should succeed, but the setData check is expected to fail. Note: The test is disabled for Sqlite3 because the use of a ":memory:" database does not allow two database sessions to interact. At this time, the unit test has only been run with Postgres.

A second attachment includes a trivial patch that attempts to address the issue. In any case, the setData check in the unit test should succeed.... There are more notes included with the patch files, which were tested with Wt 3.3.5-rc2.