Announcement Announcement Module
Collapse
No announcement yet.
Speeding up spring/hibernate startup? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Speeding up spring/hibernate startup?

    I've been using Spring+Hibernate for a long time and it's been great. I've been doing TDD for a long time as well and because of all the benefits to using Spring over other platforms and methologies, I haven't really fussed too much about the speed of the container.

    But now, as I work on a large project, I'm noticing my tests are running fairly slow inside my IDE. I'm making sure that the container is loaded statically of course and not on JUnit's setup methods (that would be really bad :P). However, sometimes it takes a good 8 to 50 seconds to load. As the project gets bigger, it's reaching that upper end and I'm not really sure why. It's like IDEA or Spring or Hibernate is doing it's own thing before the first test starts.

    As for the stuff being loaded... I have dbunit for database tests, and a ton of hibernate daos and service beans. I'm running my tests in IDEA.

    I'm working on a P4 3ghz HT processor with a gigabyte of RAM. Need to upgrade again?

    Anyone have any advice to speeding up tests when starting up the container? Thanks for your help.

  • #2
    Re: Speeding up spring/hibernate startup?

    My advice? Below is your problem. Performance tuning should ALWAYS be done with hard data, not guesses. Use a profiler or even use the poor man's profiler (System.currentTimeMillis()) and find out what is taking so long. Once you have hard data, I'm sure I and others would be happy to help tune...

    Originally posted by egervari
    ... and I'm not really sure why.

    Comment


    • #3
      Re: Speeding up spring/hibernate startup?

      Well, I'll post a full debug log when it starts up so you can see what's going on, but I was more asking for a general opinion on the start up time I gave. I mean, does everyone have very fast cycles when testing Hibernate daos directly from the Spring container as I do? Has this ever been a problem for anyone? I guess that's what I was looking for. I'll be sure to post something sometime later.

      Comment


      • #4
        Re: Speeding up spring/hibernate startup?

        I find that Hibernate takes a few seconds to initialize here. YMMV

        http://www.hibernate.org/194.html

        Originally posted by egervari
        Well, I'll post a full debug log when it starts up so you can see what's going on, but I was more asking for a general opinion on the start up time I gave.

        Comment


        • #5
          As for the stuff being loaded... I have dbunit for database tests, and a ton of hibernate daos and service beans. I'm running my tests in IDEA.
          When Unit Testing my Spring/Hibernate code, I generally reduce the Hibernate mapping needed to the minimum class(es) being tested. It happens that I use different applicationContext.xml/subset of domain.hbm.xml for each testCase. This speeds up a lot my Unit testing.
          HTH

          Comment


          • #6
            Ahh, that might be it! Since I'm loading the same applicationContext.xml for all of my tests, it is loading every HBM for every test.

            One thing that also slows down the test a great deal is dbunit itself. Because my database has so many not null foreign key constraints, I often have to load many dataset XML files. I do split the datasets up as much as I can - an xml file for each and every table, including one for many-to-many relationships. This allows me to only load the tables I want when the test class starts. However, the big service objects require the main tables in the database, which end up relating to everything else. I usually end up loading 2/3's of my test database anyway for the bigger test.

            I did some logging and there isn't anything that jumps out as taking too long except for Hibernate. Everything kind of takes a lot of time. Do you think using auto-writing to it's full potential may be the problem as well? I do use it a lot since there many, many references. I like it because it makes maintainability of the configuration file much easier.

            Comment


            • #7
              There might be some better way but we just build a dodgy helper class that manages a ThreadLocal

              e.g. to initialise

              private static final ThreadLocal context = new ThreadLocal();

              private static final ApplicationContext applicationContext;

              applicationContext = new ClassPathXmlApplicationContext(<array of Spring .xml file names>);
              context.set(applicationContext);

              .... and then to access ApplicationContext from JUnits

              public static ApplicationContext currentContext() {
              return (ApplicationContext) context.get();
              }

              Comment


              • #8
                Originally posted by gmatthews
                There might be some better way but we just build a dodgy helper class that manages a ThreadLocal

                e.g. to initialise

                private static final ThreadLocal context = new ThreadLocal();

                private static final ApplicationContext applicationContext;

                applicationContext = new ClassPathXmlApplicationContext(<array of Spring .xml file names>);
                context.set(applicationContext);

                .... and then to access ApplicationContext from JUnits

                public static ApplicationContext currentContext() {
                return (ApplicationContext) context.get();
                }
                Take a look at org.springframework.test.AbstractTransactionalSpri ngContextTests. It uses a similar approach.

                Comment


                • #9
                  As Omar points out, the org.springframework.test package (the binaries are in spring-mock.jar) was introduced partly for this reason. It caches each distinct context hierarchy once only, unless it's marked as dirty. It also provides a handy ability to run tests in a transaction that's automatically created by the superclass and rollback.

                  I've used this on several projects with dozens of Hibernate mapping files and hundreds of integration tests using Hibernate/JDBC, and with startup reduced to a one-off cost, there's a huge productivity gain.

                  Comment

                  Working...
                  X