After reading the description for that method, it's not the ideal solution.
Well, I'm sorry, but invalidating the session in the middle of a request is just not possible, since Seam needs the session state at the end of the request.
A different approach would be to not store the search results in the session context but in the PAGE or CONVERSATION scope
The containing bean is conversation scope. The search results are outjected using the @DataModel tag. If the reference remains in session, the same @DataModel list is displayed.
Would be nice to have Context.getAttributeNames, so I can clear everything out of there.
Perhaps I don't completely understand (as I don't use portlets) but that doesn't sound right to me. If you aren't propogating the conversation (s:link, h:commandLink, h:commandButton all do unless stopped using conversationPropogation) then your 'new window' (really a new window or is this a portal term?) won't have access to any other conversations so can't have data from a previous search.
Using FF 1.5
1. User logs into the portal on server 1 (some portal platform I choose not to know much about).
2. User selects a link from the navigation panel which points to server 2 (Seam).
3. User does a search and gets back results
4. User goes back to the portal window, logs out and logs back in as a different user
5. User selects the same link in the navigation panel
6. Previous user's results are displayed.
I don't expect Seam to implicitly handle this, since it's 2 different sessions on two different servers. I'm just trying to clean it up in my code when it happens.