0 Replies Latest reply on Oct 27, 2008 11:50 AM by perisb

    JBoss CMP loading behavior problem

      I am observing, via CMP log records (and poor system performance), unexpected relationship loading behavior by JBoss CMP.
      No document I've seen has been clear on how CMR works with read-ahead, so I'm not really sure what I should expect.

      The situation:

      * JBoss 4.0.2
      * Two entities, A and B, with a 1-many relationship from A to B.
      * Both entities running with the predefined 'Instance per Transaction' container configuration
      * no CMP optimizations defined, other than the default ones in standardjbosscmp-jdbc.xml:
      ...
      <read-ahead>
      on-load
      <page-size>1000</page-size>
      <eager-load-group>*</eager-load-group>
      </read-ahead>
      <list-cache-max>1000</list-cache-max>
      <clean-read-ahead-on-load>false</clean-read-ahead-on-load>
      ...

      The problem is with the following simplified code scrap (running in a stateful Session method, within a transaction):

      1) A a = ...
      2) Collection bs = a.getBs();
      3) Iterator I = bs.iterator();
      4) B b = (B)iterator.next();
      5) System.err.println(b.getFoo());
      6) while (I.hasNext())
      7) System.err.println((I.next()B).getFoo());
      8) System.err.println(b.getFoo());

      Everything is fine until line 8.

      At line 2 I see a relationship load query executed: SELECT OID FROM B where (a=?).

      At line 5 I see : SELECT OID, foo from B where (OID=?) OR (OID=?) OR ...
      The number of parameters seems to match the number of Bs that were found at line 2.
      So this looks like read-ahead to me, even though I've not specified a relationship configuration; perhaps its the default at work?
      This is evidenced by the the fact that lines 6-7 run without another query being executed.

      The problem is that at line 8, the same query as in line 5 is reexecuted!
      It appears that instances loaded within the transaction are discarded by going back and invoking on the first iterated B.
      This is not what I expect.