0 Replies Latest reply on Jan 1, 2002 2:10 AM by garyg

    container & ejbLoad

    garyg

      I've copied this over from the mailing list with a few new questions.

      In order to get ejbLoad to be called when I needed to, I've changed all ref's from A to B in the commit-options of standardjboss.xml. After I saw the # of times ejbLoad and ejbStore was called, I'm wondering how bad I've affected the performance. Do alot of ppl end up doing this, or is this out of the norm?

      After changing from A to B, it did fix my problem. What concerns me now is how I'm going to deliver my product to customers as I've had to have made several special changes like this and others to files in the ~/conf/catalina directory (which now makes installing my product w/ jboss much more difficult for customers, a very non-standard install) and would like to know how others package there products for jboss (or is it ok to just package jboss w/ it all pre-config'd).

      Thanks for the help.

      ---- below is all replies ---
      Forums are dead, so I will answer here.

      Commit option A, B, C are discussed in the ejb 2 spec section 10.5.9, and
      set in jboss typically in standardjboss.xml. They are totally independent
      of transaction demarcation using the transaction attributes Supports,
      Requires, etc. I think you want option B or C. This controls when ejbLoad
      is called.

      ejbStore will be called before the end of every transaction. If you don't
      want it to access the db, you have to put some code in so it can tell when
      something needs to be stored. The cmp2 code takes care of this for you
      completely, since it manages the field storage itself: the cmp1 code helps
      you by either saving copies of the fields and comparing (tuned updates =
      true) or letting you supply an isModified() function it will check before
      storing to the db. The container has to assume every method call modifies
      the fields, no matter what the method is called. You could have a
      getAccessCount() method that incremented the access count.

      david jencks

      On 2001.12.31 01:29:06 -0500 G.L. Grobe wrote:
      > > Maybe you have commit option A so bean is never reloaded?
      >
      > Commit option A? I don't know what this is but I'm guessing it's got
      > something to do with the transaction attribute values in the ejb-jar
      > file?
      > If so, can you tell me which one?
      >
      > > The container can't tell that your "get" methods have no side effects,
      > so
      > > it has to store before the end of the transaction. You could implement
      > a
      > > flag like isModified and check it in ejbStore.
      >
      > Is this getting into the JTA, and I need to start controlling all my
      > transactions? Though I'm using BMP, I didn't think it was anything that
      > complex where I had to do this. Once I've found my primary key, I'd just
      > like to be able to have ejbLoad called so that I could update the
      > in-memory
      > instance var and get the value from my client.
      >
      > > On 2001.12.30 19:26:35 -0500 G.L. Grobe wrote:
      > > > My problem is that everytime I call a getXXX() on an instance
      > variable
      > > > from
      > > > my client program (I'm using bmp ejb's on server), it calls the
      > > > ejbStore()
      > > > rather than ejbLoad(). In my ejbLoad is where I do sql queries to
      > update
      > > > the
      > > > in-memory instance vars so that they then become available to my
      > client.
      > > >
      > > > Shouldn't getXXX()'s call the ejbLoad and setXXX()'s call ejbStore?
      > > >
      > > > My client does sort of the following ...
      > > > ---
      > > >
      > > > Context ctx = new InitialContext();
      > > > Object result = ctx.lookup("FieldKit");
      > > >
      > > > FieldHome home = (FieldHome)
      > > > javax.rmi.PortableRemoteObject.narrow(result, FieldHome.class);
      > > >
      > > > field = (Field) home.findByPriority(IFields.HIGH);
      > > > pk = (FieldPK) field.getPrimaryKey();
      > > >
      > > > // then elsewhere in my client program I'd do ...
      > > >
      > > > if (field.getVersion() == 0) {
      > > >
      > > > // at this point, I was expecting the getVersion()
      > > > // methods to make the container call the ejbLoad()
      > > > // which would update the inmemory instance var so
      > > > // that I could get the correct value.
      > > > // ... but instead, ejbStore()'s are being called.
      > > >
      > > > }
      > > >
      > > > Am I not understanding how this works again?
      > > >
      > > > ---
      > > > Any help much appreciated.