6 Replies Latest reply on Jan 27, 2006 4:51 AM by francois.le.droff

    Defining entity bean methods results in slower execution.  W

      I am using JBoss 4.0RC2, MySQL 4.1.7, Sun JVM 1.5. I have the following test which does one create and then 1000 gets :

      public void testCreateOnceAndRepeatedlyRead() throws Exception {
       String cid = _confMgr.addConference(DTOGen.conference(1));
       String eid = _confMgr.addEvent(DTOGen.event(1,"A"),cid);
       for (int i = 0; i < 1000; i++) {
       EventDTO dto = _confMgr.getEvent(eid);
       assertNotNull(cid);
       System.out.println("testCreateOnceAndRepeatedlyRead passed."+(i+1));
       }
       }



      I then run this test 2 ways changing nothing except ADDING the following definition in JBOSS.XML :

       <entity>
       <ejb-name>Event</ejb-name>
       <jndi-name>EventHome</jndi-name>
       <local-jndi-name>EventHome</local-jndi-name>
       <configuration-name>Standard CMP 2.x EntityBean</configuration-name>
       <method-attributes>
       <method>
       <method-name>get*</method-name>
       <read-only>true</read-only>
       </method>
       <method>
       <method-name>find*</method-name>
       <read-only>true</read-only>
       </method>
       </method-attributes>
       </entity>



      The first set of tests I ran 7 times WITHOUT the above declaration in JBOSS.XML.

      32.6 secs
      24.3 secs
      25.4 secs
      23.4 secs
      23.3 secs
      24.1 secs
      23.4 secs

      Average time: 25.2 seconds to execute the JUnit test case

      Now we add the optimization to declare get* and find* to be read-only methods expeciting a performance boost.

      Repackage, redeploy, restart server.

      The second set of tests I ran 7 times WITH ONLY the above declaration in JBOSS.XML. No other changes to application or server or the machine it is running on.

      110.4 secs
      105.8 secs
      103.7 secs
      102.8 secs
      102.7 secs
      102.7 secs
      103.5 secs

      Average time: 104.5 seconds to execute the JUnit test case (same test as before)

      Can someone please explain why I would be seeing these results. The performance degradation is 104.5/25.2 = 4.1 times slower.

      I was expecting that I would actually get better performance by declaring the Event methods get* and find* to be read-only.

      I have read the JBoss docs and I am attempting to make my application run faster by making changes to the descriptor files. As you can see I have not had much luck in doing so.

      I have not tried this on older versions of JBoss. The JDBC connection pool is set to min 5 and max 20 connections. The FILE logging is set to WARN and there are no warnings or errors in either the console log or the file log.

      Could it be that my read-only declarations are not being respected? Even so, I would expect results to be the same as no declaration not 4.1 slower.

      Joe



        • 1. Re: Defining entity bean methods results in slower execution

          Can someone please explain why declaring entity bean methods read only would make the test run 4 times slower?

          Thanks,

          Joe

          • 2. Re: Defining entity bean methods results in slower execution
            goldrimtang

            Looks like JBoss will read for every column (propery of the entity bean) if the entity is not part of a transaction. With the read-only element, the entity doesn't participate on the transaciton.

            GRT

            • 3. Re: Defining entity bean methods results in slower execution

              For those who don't like to use the search function:

              read-only should only be used with commit option A
              and you should never do fine grained access of entity beans
              in multiple transactions.

              This is what is known in the trade as an "Anti Pattern".

              It is posts like this by people that don't understand the semantics of Entity Beans
              and transactions that give Entity Beans the undeserved reputation it has.

              It is the "If you people enough rope..." problem.

              • 4. Re: Defining entity bean methods results in slower execution
                goldrimtang

                Dear Adrian,

                Do not let the words 'Chief' and 'Scientist' cloud your judgement. It is not by posts like this that EJB has a bad reputation. It is by poor documentation cumbersome configuration and contradictory advice in the forums.
                Having done a good deal of searches on these forums, read wikis and docs that it took me two days to finally find a solution to the 'read-only' - 'commit-option' combo.
                I found all kind of things, including one JBoss employee giving the definitive solution: use 'clean-read-ahead-on-load'.
                You are saying that 'read-only' should be only used with commit option 'A'. So how come it is possible at all to use 'read-only with other commit options? Shouldn't we get an error message during start-up? How about at least a warning message? If this is too hard for a scientist or a chief, how about including this in the docs? May be in the 'commit-option', or 'read-only' section?
                It is very easy to be arrogant and tell other how stupid they are. It is more constructive to help and improve ourselves.
                Cheers,

                GRT

                • 5. Re: Defining entity bean methods results in slower execution

                  Arrogant == false
                  Frustrated == true at people that initially don't use FAQs/Docs/search then whine
                  because they are told to do so.

                  Your idea of warning about read-only without enabling a cache
                  is a good one, but it would require us to analyse your code to see whether you
                  are making finegrained read-only access using something other than commit option A.

                  e.g. It is perfectly valid to write a DTO method and mark it read-only with option B/C
                  because if you only invoke it once per transaction you ain't going to be continually
                  reloading the bean from the db.

                  We could certainly write an interceptor to trap your misuse at runtime,
                  however that would just slow down people that know what they are doing.
                  i.e. The microsoft nannying approach to software where the software knows
                  better than the user (maybe in your case that is true? :-).

                  The last comment is not arrogance either, it is called humour.
                  I do not really mean it. I am trying to make you ask yourself whether next
                  time it might be better use search/faqs/etc. first.

                  • 6. Re: Defining entity bean methods results in slower execution
                    francois.le.droff

                    I read the discussion with great interest,

                    But I'm still confused. If read-only is to be used only with commit option A,
                    then this statement I found on the wiki looks contradictory:

                    Note, that in case of commit option B, when a transaction first time accesses an instance (invokes CMP/CMR getter or setter or another business method) even if the instance is cached its data will be loaded from the database (re-read the spec's quote). So, the cached data is not really used. Except for one case, i.e. when the instance or some of its CMP fields marked as read-only in jbosscmp-jdbc.xml In this case, read-only fields won't be reloaded from the database.
                    http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPCaching


                    any comment on this ?
                    by the way, why did they write about jbosscmp-jdbc.xml when read-only is usually set in jboss.xml ?

                    And could you also comment on this :
                    you should never do fine grained access of entity beans
                    in multiple transactions.
                    It remains a bit blurry for me.

                    Talking about docs and wiki, I found out that read-only was indeed to be used to "relax" a pessimistic lock mechanism, as the read-only bean or method is only locked for the duration of the invocation.

                    But I didn't figure out :
                    why read-only was not to be used with other commit option than A ?
                    and how read-only was degrading the performance ?
                    Anybody could tell me ?

                    Thanks a lot !
                    Regards,
                    François.