TAP5-2619: Flash persisted value cleared too early

[Raigo Aljand <ra...@smartaccounts.eu>]

Hi,

I created the issue https://issues.apache.org/jira/browse/TAP5-2619. I 
also added a patch for fixing it. I am attaching the patch file to this 
email as well. I also copied the issue description to the end of this email.

As I'm planning in applying the same fix for my companies product, I 
would like feedback on the correctness and stability of this fix.

Regards,
Raigo

> *What happens*
>
> A page has two class fields. One is a flash persisted field (call it 
> A) and the other is a session persisted field (call it B). In a single 
> request i set field A and read field B. In the next request field A 
> has a value of null (the value is gone).
>
> *What I expect to happen*
>
> In the next request field A should have the value it was set in the 
> previous request.
>
> **I've done some research into the causes of this bug and a fix for it.
>
> *When did the bug appear*
>
> I'm certain enough that the bug appeared with the commit 
> 435997738cee2cb9ea8b4b6ec3e5227dfdb2dc91. In it, restoring the state 
> of persisted values became more lazy. If I revert the lazyness with 
> restoring the persisted field state at page attach, the bug disappears.
>
> *What causes the bug*
>
> There is an operation the result of this is cached. This is called 
> gatherChanges from persistentFieldManager. This is operation has the 
> side-effect of nulling the session value of all flash persisted fields 
> of the page.
>
> Previously this operation was called at the page attach stage. Now it 
> is more lazy and is called when a persisted field is read. But not 
> when it is set. In the buggy use case, the flash persisted field sets 
> the session value, reading the other persisted field calls 
> gatherChanges. The flash persisted field clears the field value that 
> was just set. By the next request, the flash persisted value is gone.
>
> *How to fix*
>
> The fix is to call and cache gatherChanges at setting a persisted 
> field in addition to getting it. Then the order of operation 
> guarantees correct result.
>