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