TAP5-2619: Flash persisted value cleared too early

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

TAP5-2619: Flash persisted value cleared too early

Raigo Aljand


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.


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.

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

0001-TAP5-2619-Flash-persisted-value-cleared-too-early.patch (3K) Download Attachment