Announcement Announcement Module
Collapse
No announcement yet.
All entities loaded when show method called for just one Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • All entities loaded when show method called for just one

    Hi All,

    This is rather odd, when calling planets/1 to show the first planet entry things have been running incredibly slow. I set the log level to debug and I get the following:

    Code:
    DEBUG org.hibernate.loader.Loader - result row: EntityKey[uk.co.g4me.the_ancients.model.Planet#483637]
    DEBUG org.springframework.beans.factory.annotation.InjectionMetadata - Processing injected method of bean 'uk.co.g4me.the_ancients.model.Planet': PersistenceElement for transient javax.persistence.EntityManager uk.co.g4me.the_ancients.model.Planet.entityManager
    DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Returning cached instance of singleton bean 'galaxyEntityManagerFactory'
    There are lines like this for every Planet entity that is in the database, why are all these being injected when all I want to access is one planet.

    I'm rather confused. Any light the community could shed would be highly appreciated.

  • #2
    Planets?

    Maybe you have some relationship (_ToOne, _ToMany) that eagerly needs the planets. The underlying JPA implementation (hibernate, for instance) will select all the necessary entities. And then, Spring will inject them the EntityManager (as they're @Configurables)

    Comment


    • #3
      Yes, Planets

      My initial thought was that these items were being Eagerly loaded. But:

      1) I am only requesting a load of a single Planet, no Planets reference each other.
      2) Each reference to a planet is Lazy loaded using @OneToMany(fetch = FetchType.Lazy)

      Perhaps I am setting this incorrectly?

      Is there a way to set Lazy loading globally? I'm using Hibernate.

      Comment


      • #4
        Ooops this post was duplicated
        Last edited by ArjunSol; Nov 25th, 2011, 06:25 AM. Reason: DUPLICATE

        Comment


        • #5
          From what I can see the injection of these objects happens before the show method is even invoked.

          Could this be related to my explicitly setting classes in my persistence unit?

          Code:
          <persistence-unit name="galaxy" transaction-type="RESOURCE_LOCAL">
                  <provider>org.hibernate.ejb.HibernatePersistence</provider>
                  <class>uk.co.g4me.the_ancients.model.Galaxy</class>
                  <class>uk.co.g4me.the_ancients.model.Planet</class>
                  <class>uk.co.g4me.the_ancients.model.PlanetClass</class>
                  <class>uk.co.g4me.the_ancients.model.Sector</class>
                  <class>uk.co.g4me.the_ancients.model.Star</class>
                  <class>uk.co.g4me.the_ancients.model.StarClass</class>
                  <class>uk.co.g4me.the_ancients.model.StarSystem</class>
                  <exclude-unlisted-classes>true</exclude-unlisted-classes>
                  <properties>
                      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect"/>
                      <!-- value="create" to build a new database on each run; value="update" to modify an existing database; value="create-drop" means the same as "create" but also drops tables when Hibernate closes; value="validate" makes no changes to the database -->
                      <property name="hibernate.hbm2ddl.auto" value="create"/>
                      <property name="hibernate.ejb.naming_strategy" value="org.hibernate.cfg.ImprovedNamingStrategy"/>
                      <property name="hibernate.connection.charSet" value="UTF-8"/>
                  </properties>
              </persistence-unit>

          Comment


          • #6
            It's possible.

            You know that there's no need to list the classes, don't you? The classes have an static EntityManager autowired and so do the objects, due to the @Configurable annotation.

            Comment


            • #7
              Originally posted by jbbarquero View Post
              ...You know that there's no need to list the classes, don't you? The classes have an static EntityManager autowired and so do the objects, due to the @Configurable annotation.
              Indeed, however I have two databases one user and one game and require two persistenceUnits.

              Comment


              • #8
                Originally posted by ArjunSol View Post
                Indeed, however I have two databases one user and one game and require two persistenceUnits.
                Did you try...?

                Code:
                persistence setup ... --persistenceUnit db1
                entity ... --persistenceUnit db1
                ...
                persistence setup ... --persistenceUnit db2
                entity ... --persistenceUnit db2
                I mean, the options for configuring more than one database with Roo.

                Comment


                • #9
                  Yes, all entities are configured correctly or their respective persistence units. I'm going to remove my dual setup and test to dismiss this as the cause.

                  Comment


                  • #10
                    OK, so I thought I'd simplify this and ran the petclinic sample. After adding a single Owner and three Pets the same issue exists when calling /pets/1


                    Code:
                    DEBUG org.apache.tiles.impl.BasicTilesContainer - Render request recieved for definition 'pets/show'
                    DEBUG org.hibernate.loader.Loader - loading collection: [com.springsource.petclinic.domain.Owner.pets#1]
                    DEBUG org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
                    DEBUG org.hibernate.jdbc.ConnectionManager - opening JDBC connection
                    DEBUG org.hibernate.SQL - select pets0_.owner as owner1_1_, pets0_.id as id1_, pets0_.id as id2_0_, pets0_.name as name2_0_, pets0_.owner as owner2_0_, pets0_.send_reminders as send3_2_0_, pets0_.type as type2_0_, pets0_.version as version2_0_, pets0_.weight as weight2_0_ from pet pets0_ where pets0_.owner=?
                    DEBUG org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0)
                    DEBUG org.hibernate.loader.Loader - result set contains (possibly empty) collection: [com.springsource.petclinic.domain.Owner.pets#1]
                    DEBUG org.hibernate.loader.Loader - result row: EntityKey[com.springsource.petclinic.domain.Pet#1]
                    DEBUG org.hibernate.loader.Loader - found row of collection: [com.springsource.petclinic.domain.Owner.pets#1]
                    DEBUG org.hibernate.loader.Loader - result row: EntityKey[com.springsource.petclinic.domain.Pet#2]
                    DEBUG org.hibernate.loader.Loader - found row of collection: [com.springsource.petclinic.domain.Owner.pets#1]
                    DEBUG org.hibernate.loader.Loader - result row: EntityKey[com.springsource.petclinic.domain.Pet#3]
                    DEBUG org.hibernate.loader.Loader - found row of collection: [com.springsource.petclinic.domain.Owner.pets#1]
                    This is fine if you only have three pets, but I have hundreds of thousands of planets. Colour me confused.

                    Comment


                    • #11
                      Has anybody else experienced this behavior? I had originally posted this in the data forum, apparently a mod has decided this is a ROO issue.

                      I think I'll file a jira ticket.

                      Ticket logged https://jira.springsource.org/browse/ROO-2943
                      Last edited by ArjunSol; Nov 30th, 2011, 03:50 AM. Reason: adding jira ticket

                      Comment


                      • #12
                        OK so I've tracked down the cause of this.

                        The controllers that get generated by roo have the @ModelAttribute annotation attached to several populate methods. See this for more info.

                        This causes a rather heavy query of findAllPlanets to be called and added to the ui Model on every request, even if the view doesn't require it. That's naughty.

                        At the moment my solution is to push these methods in and return null. e.g. from the pet clinic sample.

                        This method from PetController_Roo_Controller.aj

                        Code:
                        @ModelAttribute("pets")
                            public Collection<Pet> PetController.populatePets() {
                                return Pet.FindAllPets();
                        }
                        Becomes the follwoing in PetController.java

                        Code:
                        @ModelAttribute("pets")
                            public Collection<Pet> populatePets() {
                                return null;
                        }
                        But something more elegant is definitely required.
                        Last edited by ArjunSol; Nov 30th, 2011, 09:44 AM. Reason: added example fix

                        Comment


                        • #13
                          I'm glad you've found the reason. I had no time to watch this.

                          There's a POST and a JIRA ticket on this regard, but now I don't remember any of them.

                          Comment


                          • #14
                            This is a very-very sad programming issue... Unfortunately, It has been dangling there forever.
                            I reported -and fixed- long time ago in http://pragmatikroo.blogspot.com/201...libration.html.

                            What is ever more disturbing is that none of the documentation available on Roo -including books-, take care of it.

                            This just a little example of having other product advocates and book writers than the "official" ones would be on the best interest of everybody vested in SR.


                            B. Roogards
                            jD
                            Last edited by delgad9; Dec 1st, 2011, 08:58 AM. Reason: clean up

                            Comment


                            • #15
                              Hi JD,

                              The post seems to be a story of you fixing a performance issue. Sadly no technical detail at all. Would you care to go into detail? I'm sure we'd all benefit if you've found anything we may have missed.

                              Comment

                              Working...
                              X