I remember session state was hard enough when learning, particularly coming from Oracle Forms. But how is there more than one, you may ask?
98% of the time we just need to worry about the persisted session state that we all know and love. The one we see when clicking "Session" in the developer toolbar. Essentially, this is just a normal table with a session ID, item name and value.
In Memory Session State (IMMS) is the 2% that comes and bites us occasionally. Recently I had a problem the scenario described by Anton as "2A Item Rendering". His description is a little tricky, but I think this visualisation of a simpler example will help.
Some page facts:
- 'before region' has item P45_BEFORE, defaulted to A
- Region 1 has condition P45_BEFORE = A
- Region 2 (after Region 1, not visible) has condition P45_AFTER = B
- 'after region' has item P45_AFTER, defaulted to B
- The items have no source, and are just defaulted to those values shown.
- Session state (persisted) remains empty before/after. During is another story.
In this case, while it renders Region 1, IMSS will actually report a value of A for P45_BEFORE while rendering Region 1, hence it's displayed. Since P45_AFTER is rendered after Region 2, the value is null during the evaluation of the condition.
Therefore, the results differ by moving the location of the items relative to the component with the condition.
Unfortunately I couldn't find any support/explanation for this behaviour in the debug log, even at LEVEL9.
In my actual case, I had an item that stopped a report from being rendered until the user selected criteria and clicked submit. I did this by defining a hidden P1_SUBMITTED, defaulted to Y, and used that as the condition in the report.
This usually worked fine since the item is usually with other criteria in the Right Side region, but a new page had this item at the top of the page. So P1_SUBMITTED was treated as having a value Y while rendering my report, just like in the example above with P45_BEFORE.