6 Replies Latest reply on May 12, 2009 12:14 AM by gonorrhea

    Injection Question

    jnusaira

      I have a question on injection.


      So you have a bunch of services and you inject them into another service.


      Now from my understanding injection happens then at method invocation time and not after bean pool retrieval time.


      So that works great when you have objects that change from injection to injection. But if you have 10 services being injected it can take time.


      Now i was curious whats a way to make it inject only one time after bean creation?


      One solution i had was in the PostConstruct get the bean by doing COmponents.getInstnace()


      I also thought you could increase the scope of the Injected beans to?


      Or maybe just use @EJB since then the Seam interceptors should get it?



      Anyways i only ask cause this is an app where it does lots of work and throughput matters quite a bit.


      thoughts?

        • 1. Re: Injection Question

          Joseph Nusairat wrote on May 08, 2009 20:55:



          Anyways i only ask cause this is an app where it does lots of work and throughput matters quite a bit.

          thoughts?



          I think you should profile with a profiler ;-). I mean, are you sure that injection is what is going to make (or making) your application slow? I would be pointless to discuss ways of optimizing injection if it turns out that has a 0.001% effect on the performance of your application. Remember the rules of optimization.






          • 2. Re: Injection Question
            jnusaira

            Francisco Peredo wrote on May 08, 2009 22:50:



            Well we arent using profile but rudimentary timers in there via the logs.


            And so definetly initializing everything does seem to be taking the time.


            There seems to be 2 reasons for that.


            I have made all the injections Seam injections now SOME are seam components OTHER items i am using the @Unwrap to make it easier to inject our webservices and to inject some EJB2 code.


            The EJB2 code is all remote lookups. So it has to call out to one server to lookup how to lookup the info then call out to another server to actually lookitup. Actually that second lookup is local.


            ... i am guessing its these two items that are causing all the fuss as opposed to a straight EJB3 local Seam component. Probably should have been mroe clear :)

            • 3. Re: Injection Question

              Joseph Nusairat wrote on May 08, 2009 22:56:



              Francisco Peredo wrote on May 08, 2009 22:50:



              Well we arent using profile but rudimentary timers in there via the logs.



              Interesting... I proposed a profiler because I thought it was going to be hard to test injection time without it...  where do you put the log messages to precisely measure the time it take to inject stuff?



              And so definetly initializing everything does seem to be taking the time.

              There seems to be 2 reasons for that.

              I have made all the injections Seam injections now SOME are seam components OTHER items i am using the @Unwrap to make it easier to inject our webservices and to inject some EJB2 code.




              So.. the EJB2 remote objects are the slow ones? How slow? (0.1 seconds for each injection? more?)



              The EJB2 code is all remote lookups. So it has to call out to one server to lookup how to lookup the info then call out to another server to actually lookitup. Actually that second lookup is local.



              And you are sure that what is slow is the injection and not the call to the remote methods of the injected EJB? Did you measure that too? How?



              ... i am guessing its these two items that are causing all the fuss as opposed to a straight EJB3 local Seam component. Probably should have been more clear :)



              • 4. Re: Injection Question
                brandonsimpson

                I've also been a little concerned about bijection overhead. And I'm pretty sure it can make a difference...if you read one of Dan Allen's recent blogs where he optimized an app he was working on, I think it does show that there is some measurable overhead. Relative to other things, it was small, but still...if you are working on eking out the very last bit of performance, I think you'd have to minimize the amount of unneccessary bijections.

                • 5. Re: Injection Question
                  jnusaira

                  My other developer went through and moved them all to the post constructs and it has added quite a bit of performance apparently.


                  I am still a bit surprised by the performance gain ... but as i said it kind of a high throughput system. Or at least attempts to be.

                  • 6. Re: Injection Question
                    gonorrhea

                    the way I understand bijection according to SiA book is the following:


                    injection, outjection and disinjection occur every time a business method is executed (and in the case of outjection, that only happens if the method successfully completes with no runtime exception thrown).


                    it's dynamic injection, not static (one time) injection like Spring.  so there is an advantage and disadvantage there depending on whether or not you need injection to occur to keep the context variables in you Seam component fresh or not.


                    In your case, it sounds like you need static injection in some or all cases for that specific use case or project.


                    I don't know how to conveniently (i.e. @In(static="true")) specify a particular context variable to be injected only once in Seam...


                    Your question is in the same bucket as the question I raised recently on this forum regarding finer-grained injection control.  How can we injection the x context variables dynamically for these y business method(s) only?  Not inject all context variables marked @In for all business methods...


                    Perhaps you could use a Spring bean in your case?