5 Replies Latest reply on Dec 17, 2001 3:42 AM by steinarc

    Coarse-grained Entity-beans

    segerss

      I am relatively new to J2EE (classic opener, but still true) and have started reading the book core J2EE Patterns.
      In this book it is suggested that it is best to define coarse-grained beans because performance decreases when you have to many beans. Because coarse-grained beans present could be quite heavy to load/store they then suggest to implement lazy loading and store optimization in these beans.
      My idea however was to define fine-grained beans and let the container to all the persistence-optimization for me. Is this a good strategy?

        • 1. Re: Coarse-grained Entity-beans
          marc.fleury

          coarse grained:
          pro: little network overhead, but if you are running all in vm (as in JSP accessing the EJB) then you really don't pay the price of the serialzation with JBoss so that argument is no longer valid in other words going coarse doesn't buy you anything.
          con: load store can be a bitch (too much data) you need to be careful to implement "isModified" and other optimizations in JBoss

          fine:

          pro: load/store granularity and speed,
          con: none given the optimization point above (in network).

          Bottom line: don't believe everything you read in books, unless they come from us. Come to the training, we cover these points in great details.

          • 2. Re: Coarse-grained Entity-beans
            ted_graham

            > coarse grained:
            > pro: little network overhead, but if you are running
            > all in vm (as in JSP accessing the EJB) then you
            > really don't pay the price of the serialzation with
            > JBoss so that argument is no longer valid

            If you are using other kinds of clients, you will have to pay the serialization price. If you have an application for a client, it won't be in the same VM as the beans.

            Ted

            • 3. Re: Coarse-grained Entity-beans
              drfish


              > If you are using other kinds of clients, you will
              > have to pay the serialization price. If you have an
              > application for a client, it won't be in the same VM
              > as the beans.

              I would think the best way to solve this and provide the "best of both worlds" would be to use fine grained entity beans for data, and for client access provide coarse grained session beans to aggregate the fine grained eb's. This concept is reinforced by the new "local ejb" spec - of course with JBoss's intra-vm optimization the local ejb interfaces seem to be superfluous.

              That of course leads to the second question in this realm I keep coming back to - why are local and remote ejb interfaces "exclusive"? ie, if you write your code to local interfaces, the local beans cannot end up distributed without re-code.. to me the automatic intra-vm optimization in JBoss is a much more usefull mechanism - if you have entities wraped by session, and they are in the same vm, you get high performance optimized calls, and if not, you get standard remote calls...

              If someone could shoot down my thought, please do with some facts/examples so I can stop thinking this way! It often seems that what sounds good in "theory" dosnt work in reality!

              • 4. Re: Coarse-grained Entity-beans
                vincent

                > I would think the best way to solve this and provide
                > the "best of both worlds" would be to use fine
                > grained entity beans for data, and for client access
                > provide coarse grained session beans to aggregate the
                > fine grained eb's. This concept is reinforced by the
                > new "local ejb" spec - of course with JBoss's
                > intra-vm optimization the local ejb interfaces seem
                > to be superfluous.
                >
                > That of course leads to the second question in this
                > realm I keep coming back to - why are local and
                > remote ejb interfaces "exclusive"? ie, if you write
                > your code to local interfaces, the local beans
                > cannot end up distributed without re-code..
                > to me the automatic intra-vm optimization in JBoss
                > is a much more usefull mechanism - if you have
                > entities wraped by session, and they are in the same
                > vm, you get high performance optimized calls, and if
                > not, you get standard remote calls...
                >
                > If someone could shoot down my thought, please do
                > with some facts/examples so I can stop thinking this
                > way! It often seems that what sounds good in "theory"
                > dosnt work in reality!

                IMHO local interfaces are useful for internal fine grained entity beans. But not for external one.
                Let me explain with an example,
                You have an Order and a OrderLine entity beans, you wrap OrderLine by local IF inside Order and you wrap Order by local IF inside OrderSession.
                You deploy the 3 in a jar itself in a ear.
                If you want to use Order (not OrderSession) inside another ear, you can...if it has been deployed using with remote IF.
                In other words Local interfaces does not solve completely the issue of isolation of beans and was only introduced to permit fined grained entity beans in non clever EJB containers ;)

                • 5. Re: Coarse-grained Entity-beans
                  steinarc

                  Seems to me that the conclusions are: No benefits from coarse grained EJB's if web container and J2EE container is running in the same JVM. On the other hand if you are running the web container in one JVM and the J2EE container in another, you definitly want to use coarse grained beans and value objects.

                  I guess using coarse grained beans and value objects enables your application to scale better when the time comes that you need to install more servers. I.e. having JBoss on one server (HW node) and Tomcat on another.

                  Personally I'm not too fond of having my application servers, web servers etc. connected to a terminal window, I much prefer having them run as services, hence I've configured my box with JBoss and Tomcat in separate JVM's due to the fact that Tomcat installed itself as a service straight out of the box.

                  Are my conclusions completely wrong I wonder? Since I shall start coding my application in just a few days, I really don't want to make the wrong conclusions :-)