tags:

views:

547

answers:

2

We have a search form where the filter is bound to a property on a managed bean (session scope). It's not component binding, its property binding like <h:inputText value="#{searchBean.filter}"/>.

Submitted data from different machines (different sessions, then) is getting mixed. You search "john", and get "mary" just because the guy beside you have just searched "mary". The value of your searchBean.filter is getting his submitted data instead of yours.

I've already googled around a lot and found no solution, just an ocurrence of the same problem.

Have anybody faced this issue already? Any clues?

Thanks!

+3  A: 

This can have two causes:

  1. The bean is actually in application scope.
  2. The property in question is declared static.

To fix 1), just ensure that it's in session scope.
To fix 2), just remove the illegal modifier.

BalusC
Thanks for answering, Balus! Unfortunately, neither one is happening. I've just ensured that the bean is in session scope and the property is not static.
Jaú
Are it actually two physically different machines? How did you actually test it? Firing two instances of the same browser does not use different sessions. Best test would be then to fire one instance of two different browsers each (e.g. one of IE and one of FF). You could debug the Session ID by `${pageContext.session.id}` in page.
BalusC
As incredible as it may sound, they're two physically different machines, on different tables, with different people operating them.
Jaú
How about session ID? How about other session scoped attributes? How about the listeners/validators/converters? They do not hold some static/instance-specific data do they?
BalusC
Using debugging and a tracing `PhaseListener` I could realize that the session scoped bean stops interacting with JSF lifecycle after a new user comes in. Although the right values flow through the lifecycle, it ignores input and don't pass output back to JSF after INVOKE_APPLICATION either. Trouble is I still have no clues about the causes. I've also checked listeners/validators/converters as you advised above, but unfortunatelly that wasn't the case.
Jaú
Then I don't see any possible cause unless you didn't elaborate the problem very well. Is it maybe the **result** instead of the **input** which is been shared among sessions? If so, then double check your data layer. The DAO classes, SQL statements and so on. They should also not hold data as static/instance variables.
BalusC
I'd be happy if the problem were on DAOs, but I've checked them already. The code isn't mine. I'm about to give up fixing this thing and re-implement it. Well, thanks very much for your effort trying to help. I'll post here the end of this scary story. :-)
Jaú
+1  A: 

Solved! Finally. Thanks guys, for your attention!

It was something like what Balus guessed at the first time. It was a static hidden in a dark corner. I had really double, triple checked everything looking for statics, but -- don't ask me why -- someone created a second bean (Foo) which was holding a static reference for SearchBean.

In the JSP, there was an action="#{foo.search}" instead of searchBean.search. Class Foo had a method with the same name as in SearchBean, that was doing no more than a searchBean.search();.

I think pressure for fixing this bug for yesterday didn't allow me to see this trap in the JSP.

Jaú
Glad you solved it. Threadsafety issues always boils down to scoping issues (i.e. incorrectly being application or session scoped, or just declared static). Funny that there was a clash with other's code. Maybe been uncareful with some CVS? Anyway if the question is answered please don't forget to set the accepted answer.
BalusC