Daniel Niklas schrieb:
Hi Simon,
Simon Kitching wrote:
The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can
guarantee to support a certain number of back-button clicks - at the JSF
level at least.
Or that when two windows are open on the same webapp, that the user can
perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the other
window starts to misbehave.
Ok, our application doesn't need something like that, because we have
session beans...
If you have session-scoped beans, and your users are not prevented from
using the back-button then you *will* have problems.
Note that there are two quite separate issues here:
* having the jsf view correctly restored after "back" button
* having your backing beans correctly handle the user leaping around
the application in unexpected ways (which is what "back" and "forward"
buttons look like to the server code).
The core we are talking about here does solve the first one, but doesn't
even try to solve the second.
Simon Kitching wrote:
The "weak" map stuff then tries to make life nice for the user; when
there is memory to spare then it tries to keep as many old views as
possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks will
work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks are
guaranteed to work.
It might be a problem, that many of these objects are created and
the memory increases very fast. That means much effort for garbage
collection!
And most people (?!) doesn't need this mechanism at all.
If you've found a way to stop users using the "back" button, please tell me!
I've found that even threatening them with a large ice axe isn't enough
to keep their paws off that button.
Ordinary users *really* like the idea of "back" as an option.
Simon Kitching wrote:
The original code used the default constructor for ReferenceMap, which
uses strong refs to keys but weak refs to values. The key object here is
not large; it is the value (which is the whole UIViewRoot) that is held
weakly. However nothing *ever* clears the keys for this map.
Yes, 1.1.5 uses the default constructor for ReferenceMap. But this
was not the problem! Entries of ReferenceMap will be removed when the
garbage collection runs (and there is no other hard reference to
the value), even if the corresponding key is hardly referenced!
No memory leak here.
I suspect think there is. A ReferenceMap will have internal data
structures. I haven't checked the code, but would guess that these are
only cleaned up when methods are called on the referencemap.
Regards,
Simon
