I partially worked around this issue by making an arbitrary finder call (within the appropriate run-as context) after updating BeanB, so that BeanB's ejbStore is called with the correct run-as context. The remaining issue is basically a potential security hole. Say you deploy two EAR files in a JBoss instance. It might be possible, using the invalid run-as security context within an ejbStore call, for the software in one archive to call software in the other archive that it shouldn't be able to call (as long as it's all in the same transaction). I suppose one workaround would then be to not let a transaction span two different beans that didn't completely trust each other. Of course the sacrifice there might be data consistency in the application. Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048770#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...