I write to mention an issue I recently encountered that may be viewed as a
bug, but at least something to be aware of when using tapestry
@ApplicationState
I have substantial ApplicationState object that I use from most of the pages
within a single view webapp. I create the ASO manually on successful login
and destroy it on logout (or session termination). I only create the object
if there is no object yet created in the session using the boolean ASOExists
variable. However, I found from my logs that if a user clicks the "login"
button multiple times, the form is posted multiple times, and in some cases,
more than one instance of the ASO is instantiated. In my case, since the
constructer of the ASO can sometimes take a few seconds this happens more
frequently than probably most other use cases, but it
is definitely happening.
So here's code in the login page:
In my Login.java class:
...
@ApplicationState
private SessionCredentials sessionCreds;
private boolean sessionCredsExists;
....
private void setupSessionState(String ua, String serverName) {
if (!sessionCredsExists) {
sessionCreds = new
SessionCredentials(library, am, prefs, ua,
ms, sess.getId(),
serverName);
}
}
...
So, basically, if I post multiple times and the SessionCredentials
constructer doesn't finish and return before the next post reaches this
function, the sessionCredsExists will not yet be set to true (since it's set
once the variable is assigned and then put in the Session) then we have two
instances created for the same session (which is a nono for my app). In my
case, the first instance is retained elsewhere (so that I can properly clean
things up on logout/session expiration), so it isn't just garbage collected.
However, I can think of times when having two instances of an ASO per
session could be maybe more damaging than just a memory leak.
My solution (tell me if I'm missing something easier or doing something
harmful) is just to synchronize in this method on the session, so there will
be only one ASO created per session.
Comments?
