Article:		JBoss Optimizations 101
Subject:		How to utilize this with a session facade
Date:		2003-06-09 19:27:33
From:		anonymous2
Response to: How to utilize this with a session facade
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

Showing messages 1 through 5 of 5.

• 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

• 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