Using Thread.wait()/Thread.notify() comes to mind. (*Chris*) On Sun, Apr 26, 2009 at 9:18 PM, Dale Newfield <d...@newfield.org> wrote:
> Wes Wannemacher wrote: > >> One issue findbugs points out is that the BackgroundProcess constructor >>> starts it's thread before returning, which means that any subclass won't >>> get to finish it's constructor before the thread is started. This is >>> relevant to the solution offered at >>> >>> http://cwiki.apache.org/WW/hibernateandspringenabledexecuteandwaitintercept >>> or.html and I'm not sure if it's really an issue or how to fix it (but >>> I'm >>> interested since I use something like that in my current project :-). >>> >> >> I'm looking at BackgroundProcess and it looks like the only thing that >> happens after .start() is some exception handling logic... I'm not sure as I >> haven't had to deal with multithreading issues for a long time (and I don't >> even think I was using Java the last time I had to think about it). But, it >> doesn't seem like a real issue to me. Of course, I'd concede if someone more >> fluent jumped in and pointed out that I'm wrong. >> > > After looking at this a bit more I believe that the struts2 code is > correct, but that OpenSessionBackgroundProcess on that wiki page has a race > condition. The problem is that the constructor of this object starts > another thread that immediately starts interacting with this object, > potentially before this object's constructor is even done running. As you > said, t.start() is the last thing that happens in the constructor of > BackgroundProcess, but the one line left in the constructor of > OpenSessionBackgroundProcess is recording a useful piece of information > (sessionFactory) that is assumed to already be set at the beginning of > beforeInvocation(), but might not be set yet when beforeInvocation is > invoked. > > I believe the dumb fix is as simple as adding a member "initialized" to > OpenSessionBackgroundProcess that starts at false and is set to true as the > new last line of OpenSessionBackgroundProcesssessionFactory's constructor, > and adding a busy-wait loop at the beginning of beforeInvocation() that > calls Thread.yield() until the initialized field goes true. I'm certain > that there's a better solution than a busy-wait loop, but it's past my bed > time, so I'll think about that more in the morning. The obvious solution > (synchronized methods) won't work to avoid simultaneous execution of both > the constructor and beforeInvocation, because a constructor cannot be > synchronized. > > -Dale > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
