Re: [jboss-dev] Change in locking behavior in MainDeployer [WAS: Port conflict in tx manager - cluster-udp-SYNC-0

I must admit this write locks were introduced on a quick intuition. :-( As this turns out, they definitely need more thought into. But it should also take into an account proper "disrupted" boot. Sent from my iPhone On Feb 19, 2009, at 23:17, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > Ales Justin wrote: >> I can see what the problem is, >> just dunno what the proper solution would be. >> I'll check tomorrow, but any suggestion is welcome. > > I don't fully understand the design intent of all this, but I'll > engage in some speculating anyway. ;) > > 1) Is the reason you changed MainDeployerImpl.process() from a shared > lock (lockRead() call) to an exclusive lock (lockWrite() call) because > only a single thread at a time can be allowed to call > deployers.process()? If so we're stuck. > > But the JIRA this change was made to fix[1] says nothing about needing > to prevent concurrent calls to deployers.process(...) so I'm hopeful > that's not it. > > 2) Or is the reason you went from a shared lock to an exclusive lock > because of the change in the call pattern to deployers.process(...) ? > i.e. > > WAS > > deployers.process(deployContexts, undeployContexts); > > NOW > > deployers.process(null, undeployContexts); > ... > processToDeploy(); > ... > deployers.process(deployContexts, null); > > So now you've got two deployers.process() calls with work in between > and you want to ensure no other thread jumps in the middle? > > If yes, since to get to question 2 we determined in question 1 that > deployers.process() calls can be concurrent, is making the two calls > atomic necessary? Looking at DeployersImpl.process, all it does is > process the undeploy list and then the deploy list. The only thing > different with how you're using it now is the work you are doing in > processToDeploy() adds a greater time gap between the two steps. > > 3) Or, the shift to the exclusive lock was just to protect some of the > internal data structures (which I doubt). In that case the solution > seems like some more fine-grained locking that isn't exclusively held > during the calls to deployers.process(). > > [1] https://jira.jboss.org/jira/browse/JBDEPLOY-159 > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development