How should we address our Search Templates not being thread-safe?
I've recently been looking into making the MAFSession object properly Serializable.
As I descended deep into MAFSession's object graph, I came across a potential problem with Search Templates.
* For China, tuju, wlhk, wlie, wlin, wlmy, wluk, there is a `` element defined for some templates, which is updated from the user's Preferences
* This is used for "Terms in context" for all but tuju, which uses it to select a user's preferred region
* Similarly, for laley, laley-cp and wldk there is a `` element defined for some templates, which is updated from Oasis
The problem is this:
In production (in fact, generally on any server other than one running locally), the Search Templates are cached, which means that the Search Templates, it and all its constituent objects should be immutable!
Suppose we have two users of WLUK:
* User A has the "Terms in Context" preference set
* User B doesn't have the "Terms in Context" preference set
Suppose they both access the WLUK home page at the same time, this will display the *std-searchall* template, modifying the value for the "Terms in Context" according to each user's preference. Now, if we're really unlucky with timing, it could happen that User A could see the home page with the "Terms in Context" checkbox unchecked even though it's been set in their preferences. I have been able to reproduce this locally in debug mode by having two users logged on and pausing each user's thread at the right time.
Obviously, this also applies to any other Preference or Search Template setting, and also applies to components of Search Templates, which have setters as well. As we're caching Search Templates, it and all its objects should be immutable!
Finally the questions are:
* Has anyone seen these issues in production?
* How should we go about fixing this?
