-
1. Re: @In on SESSION scope component
gbc1 Sep 19, 2007 4:59 PM (in response to gersonk)Afaik stateless sessionbeans are held in a pool by applicationsserver. When invocation takes place seam intercepts activation and refreshes injected properties from contexts. But don't know if every @In property is always been injected new on every access or so.
Greetz GHad -
2. Re: @In on SESSION scope component
matt.drees Sep 19, 2007 5:10 PM (in response to gersonk)Yes, no matter what the scope is, dependency injection occurs for every method invocation (except re-entrant calls).
-
3. Re: @In on SESSION scope component
monkeyden Sep 19, 2007 5:22 PM (in response to gersonk)Yes, we had some HUGE performance problems until we realized this. We have a relatively large form that was getting killed because of it.
-
4. Re: @In on SESSION scope component
gbc1 Sep 19, 2007 5:43 PM (in response to gersonk)Well CR1 gave my huge performance boost and for my own inetrceptor I created a blacklist. This way the interceptor is able to forget not relevant methods and fields and only continues processing when it is necessary. Save a lot of runtime when the interceptor can concentrate on his issues when it is really needed. Or I may use beanutils... must go exploring..:-)
Greetz GHad -
5. Re: @In on SESSION scope component
gersonk Sep 19, 2007 5:54 PM (in response to gersonk)thanks.
"monkeyden" wrote:
Yes, we had some HUGE performance problems until we realized this. We have a relatively large form that was getting killed because of it.
Interesting...
But even the form is so large, I suppose that Seam Interceptor basically just copy the object's reference to the attributes that have 'In' annotation. I can't see a huge cost of performance in that operation. (ok, the interceptor do much more than I described, but I can't see why a large form could slow down the performance in that way).
Could anyone explain it? -
6. Re: @In on SESSION scope component
monkeyden Sep 20, 2007 12:48 PM (in response to gersonk)We're use i18n. In addition to the business processes of the actions, we were doing a lot of single message injection, using EL, which required parsing and evaluation of the expression and retrieval from the map.
Sure, a cursory assessment says bijection itself is not a problem, but when you have 25-30 value-binding methods called and 5-10 possible validation error messages bijected from your resource bundle, you take a vastly different approach to your implementation.