I should have learnt from school - "read the question!" - so I've had a quick look at the source code.
I see now, having read a bit more, that you are performing the locking/checking to see if the action class itself needs to be instantiated. So at the moment, every time an action needs to be accessed, the code uses the double check locking (DCL) to determine if the Action class needs to be instantiated. But the DCL has been shown to be problematic. The new code in bug 2214 attempts to solve this by performing a synchronised lazy instantiation, which now involves 2 synchronisation steps that are not conditional anymore. I would have thought that this is going to create a performance issue as this synchronisation will happen on every request now, won't it? Would it not be more appropriate to scan struts-config at initialisation and instantiate an instance of all the declared action classes? Then this would obviate the need for any synchronisation when attempting to reference an action object. Now just let me look over the question again.... Andy (BTW, I'm not a multi-threading wizard, just some smuck with a big keyboard) ----- Original Message ----- From: Andy Noble <[EMAIL PROTECTED]> To: Struts Developers List <[EMAIL PROTECTED]> Sent: Sunday, December 02, 2001 11:18 PM Subject: Re: Multiple controller servlets > > > > Do any multi-threading wizards out there have an opinion on > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2214 > > > > At the moment, the 'getActionInstanceLock' method returns an object for the > action class to ensure that there is effectively one monitor (lock object) > for each action class. However, this code has to be synchronised in case the > lock object doesn't exist and needs to be created. > > To avoid having to synchronize on the 'getActionInstanceLock' method, would > it not be better to have the Action class create an entry for itself into > 'actionInstanceLocks' collection during the class initialisation? Or use the > action class object itself instead? > > Andy > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
