Women in Technology

Hear us Roar



Article:
  JBoss Optimizations 101
Subject:   How to utilize this with a session facade
Date:   2003-06-09 16:00:44
From:   anonymous2
Having a bunch of entitybeans and some CMR fields I experience a problem setting all get* methods read-only. My session facade sometimes gets a collection of CMR interfaces and want to add or delete a member of the CMR collection. The read-only attribute of those CMR getters won't allow this, jboss mumbles "This collection is a read-only snapshot". On the other hand, I'd like to keep the read-only attribute for those cases where the CMR stuff is really read-only.


Does it make any sense to put the read-only attribute on the business methods in the session bean facade instead? This would solve my problem, but it doesn't intuitively sound like one can do this. Do I have to make duplicate entity beans in order to have one version that is complete read-only for all getters and one who is only read-only for non-cmr fields (getters) that I can use in the methods that actually need to update cmr fields?


I've also read in the jboss forums that cmr fields shouldn't be declared with abstract getters and setters in the ejb (or interfaces), only in ejb-jar.xml? I have found this strange, and all my entity benans have their cmr-fields declared as abstract getters and setters in the beans. Is this somehow wrong and perhaps the cause of the problem?


--
Jon Martin Solaas
jonmartin.solaas@mail.link.no
www.objectlabs.no

Full Threads Newest First

Showing messages 1 through 6 of 6.

  • How to utilize this with a session facade
    2003-06-09 19:27:33  anonymous2 [View]

    The read-only tag in jboss.xml (and not the one in jbosscmp-jdbc.xml) is about enrollement in the current transaction and locking. Consequently, it has no sense in the case of a session bean (but only in the case of an entity bean. In your case, you may simply want to deploy the same EJB twice: one with RO, and one witout RO.

    Cheers,


    sacha
    • How to utilize this with a session facade
      2003-06-09 23:56:55  anonymous2 [View]

      Uh, why didn't I think of that myself ... :-)

      Thanks!

      --
      jon martin solaas
    • How to utilize this with a session facade
      2003-06-10 01:19:49  anonymous2 [View]

      Just a little follow-up-question:

      Do I have to make new RO relations as well?

      Suppose I have a PersonEJB with a CMR (recursive, if that matters) collection Children.

      So I make another deployment of PersonEJB, called PersonEJBRW, with <read-only>false</read-only> markup for the getChildren method, in ejb-jar.xml. I just copy the <entity>-section for PersonEJB and changed <entity-name> and <display-name>. In addition new <containser-transaction> specs for all methods are added (or could I "inherit" those somehow from PersonEJB?)

      I update jbosscmp-jdbc.xml so that both beans uses the same table, and I have a special entry for PersonEJBRW in jboss.xml specifying that all getters _except_ getChildren is <read-only>true</read-only>

      I suppose I must make new CMR-relations as well in ejb-jar.xml?

      So, basically, my question is; what have I forgotten here? I can't believe I've figured it out on the first try, that'd be very much unlike me :-)

      --
      Jon Martin Solaas
      jonmartin.solaas@mail.link.no
      • How to utilize this with a session facade
        2003-06-10 01:34:16  anonymous2 [View]

        Hi, it's me again :-)

        Believe it or not, I have even more questions.

        I somehow think the method outlined in my previous posting is a bit overwhelming. I'd have to update three xml-files and provide separate lookup code for different versions.

        Wouldn't it be easier to just provide two getters for the same relation, and just alter the client code slightly, ie. when I just want to display a list of children I'd just call getChildrenRO(), while I'd call getChildrenRW() when I want to add or delete children in the collection.

        Still I'd have to provide a separate relation in ejb-jar.xml, but the amount of xml-configuration would still be significantly lower, which I think is a good thing.

        I don't know if this would work, but I'd like to get a hint here, I guess I could dream up one crazy scheme for implementing this kind of optimization after the other, and it's just end up as a horrible mess.

        --
        Jon Martin Solaas
        jonmartin.solaas@mail.link.no
        • How to utilize this with a session facade
          2003-06-10 07:43:05  anonymous2 [View]

          I think that I would redeploy everything that is required twice, and not try to mess up my code by creating dummy relationships or things like that. That is really a deployment/configuration issue and not a development issue.

          Cheers,


          sacha
          • How to utilize this with a session facade
            2003-06-10 12:20:55  anonymous2 [View]

            Clearly it's best to keep this a deployment issue only. But creating relations is done in ejb-jar.xml just like the re-deployment of the bean itself, so I don't see how it'd mess up code, and the only reason to declare such a relation would be to use it, so it wouldn't exactly be a dummy relation either.

            Also, I wasn't aware that the re-deployed ejb would inherit the relations from the first deployment. Is it really so? After all, when a relation is declared in ejb-jar.xml, it's associated with <ejb-name> which would be different for the two deployments of the same EJB. I figured the container wouldn't attempt to create any implicit relations. Actually that doesn't make any sense at all, so I guess i must have misunderstood something.

            Now, for the practical solution to my problem; I've just coded around it, sticking with exactly the optimization described in the article. I just don't try to modify the read-only cmr-collections returned by the getters, I create new collections that I write back using the setters instead. I suppose this has some overhead, but it's neglectable compared to the gain using read-only optimization in the first place (in my app, where not many updates are made, that is). This way I have changed my code slightly, but not more than I'd have to do to look up my RW-redeployed beans where needed. I also save a large amount of xml-descriptors, which wouldn't be so nice to maintain, I guess.

            --
            Jon Martin Solaas
            jonmartin.solaas@mail.link.no