Finally realised what was going on with this. I had a LoginAction: @Stateful | @Scope(ScopeType.EVENT) | public class LoginAction implements Login, Serializable | { | @Out | SessionTimeoutHander sessionTimeoutHander; | | ... | | public String login() { | ... | | sessionTimeoutHander = Component.getInstance("sessionTimeoutHander"); | | ... | } | } If a user had made a successful login twice within the same HTTP session (e.g. login, hit back button, login again - surprisingly, this scenario shows up quite a lot in my access logs!), the call to getInstance() would introduce a duplicate object. When the SFSB destruction code ran, I got the ConcurrentModificationException. The solution was to handle the creation of the sessionTimeoutHandler using a regular @In(create=true) against sessionTimeoutHandler and remove the call to getInstance(). I was assuming that my code above was equivalent to @In(create=true), but clearly it is not. Although there was no apparent problem in my application, because of exception raised during the SFSB clean-up there may be a potential memory leak situation since EJB3 cannot successfully destroy objects. The exceptions were recurring which would suggest that the objects are being held onto which supports this theory. Hope this helps, Cheers, Chris. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016302#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...