A while back I looked at the Vaadin Plugin and tried to make it work with the Multiton PureMVC. Back then I proposed the following code:
public static ApplicationFacade getInstance() {
if (instance == null) {
// nuke the multiton so we can do the grails recompile
if (ApplicationFacade.hasCore(CORE)) {
ApplicationFacade.removeCore(CORE);
}
instance = new ApplicationFacade(CORE);
}
return instance;
}
A little more noodling and you’ll see that doesn’t work. In a multi-session environment, each user will need his own core. Furthermore, inactive cores should be harvested, otherwise we will have a memory leak.
A little repair work and we have the following code, which does half the job:
public static ApplicationFacade getInstance(HttpSession session) {
String id = session.getId();
if (instance == null) {
// nuke the multiton so we can do the grails recompile
if (ApplicationFacade.hasCore(CORE + "_" + id)) {
ApplicationFacade.removeCore(CORE + "_" + id));
}
instance = new ApplicationFacade(CORE + "_" + id));
}
return instance;
}
We get the session through the Vaadin ApplicationContext object. So, now we get a fresh core per session. But we still have the problem of leaking memory every time a session or Vaadin application is invalidated. Neither PureMVC nor Vaadin have any lifecycle methods to hook into for cleanup. In PureMVC that is understandable, since it isn’t really designed for a web application context, but this seems a more serious oversight in Vaadin.
We can hook some PureMVC cleanup by storing the key as a session attribute and using a HttpSessionListener to clean it up. I’ll test that out and blog about it in the future.
