advertisement

Article:
  JBoss Optimizations 101
Subject:   How to utilize this with a session facade
Date:   2003-06-10 07:43:05
From:   anonymous2
Response to: How to utilize this with a session facade

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
Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • How to utilize this with a session facade
    2003-06-10 12:20:55  anonymous2 [Reply | 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