"alesj" wrote : "adrian(a)jboss.org" wrote : | | then they might end up processing each other's stuff but they won't miss one. | I wasn't thinking about missing one. | I had this in mind (#t = #thread): | | 1t - addDeployment | 1t - process | | While 1t is just done with process' undeploy part, but before it enters processTopDeploy, 2t does addDeployment, but it's really re-deploy. | Meaning it will add its previous context to undeploy, which wouldn't be | processed until 2t calls process, but itself would be picked-up by 1t's processToDeploy. | In this case the 2t's re-deploy's undeploy wouldn't happen, only deploy, | which can lead to whatever. :-) Ok, I see your point, but that's not a reason to use the write lock which is for a different purpose. I can see two possible fixes: 1) Have a seperate toRedeploy list you can snapshot where "processUndeploy()" adds those to the "toUndeploy" snapshot and creates an entry in the real "toDeploy" list. 2) Don't move a "toDeploy' request into the snapshot while it exists in the real "toUndeploy" list. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211796#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...