Hello, IMHO, it would be better to use java concurrency package now than to use the old synchronize mechanism. The old mechanism is to low level and error prone. I think you could have a thread pool and some handler pattern to handle the request from your customer.
2009/5/8 Andre-John Mas <aj...@sympatico.ca> > > On 7-May-2009, at 19:05, David Kerber wrote: > > Andre-John Mas wrote: >> >>> >>> That would be my impression too. It is best to avoid making the >>> synchronized scope so large, unless there is a very good reason. >>> >>> David, do you have any reason for this? Beyond the counter, what other >>> stuff do you synchronise? Also, it has generally been recommended to me to >>> avoid hitting the disk in every request, since you may result with an I/O >>> bottle neck, so if you can write the logs in batches you will have better >>> performance. If you know that you are only going to have very few users at a >>> time (say, less than 10), it may not be worth the time optimising this, but >>> if you know that you are going to get at least several hundred, then this is >>> something to watch out for. >>> >> >> Thanks for the comments, Andre-John and Peter. When I wrote that app, I >> didn't know as much as I do now, but I'm still not very knowledgeable >> about synchronized operations. >> >> The synchronized section doesn't do a whole lot, so it doesn't take long >> to process. My question is, what kinds of operations need to be >> synchronized? All I do is decrypt the data from the POST, send a small >> acknowledgement response back to the site, and write the line to the log >> file. Does that sound like something that would need to be >> synchronized? If not, pulling that out would be a really easy test to >> see if it helps my performance issue. >> >> > I am no expert in this myself, but I know enough to help me out in most day > to day scenarios. What you should be reading up on is concurrency in Java. A > few useful resources: > > site: http://java.sun.com/docs/books/tutorial/essential/concurrency/ > book: > http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 > > I actually bought the book myself and find it a handy reference. > > What I can say is that any time two threads are likely to access the same > object, which has the potential to be modified by one of them, then you will > need to synchronize access to the object. If the object is only going to be > read during the life of the "unit of work", then you will need not > synchronize it. You shouldn't simply use the synchronize keyword as a > magical "solve all" for threading issues and instead need to understand what > the nature of the interactions are between the threads, if any. In certain > cases it is actually better to duplicate the necessary resources, have each > thread work on its copy and then synchronize the value at the end. > > In the case of your code, you should ask what are the shared objects that > are going to modified by the threads. You should also look if it is even > necessary for the objects to be shared. Also consider whether for the call > cycle the objects you are going to modify are only available on the stack, > as opposed to a class or instance member. > > To give you a real world analogy: consider a home that is being built and > you have an electrician and a plumber: > - is it better to have one wait until the other is finished (serial > execution)? > - is it possible for them to be working on different stuff and not be > stepping on each other's feet? (parallel execution) > - if you need them to work at the same time, what is the cost of > coordinating each other so that > they do not interfere with the other? (synchronization issues) > In many ways multi-threading is not much different, and you should be > asking yourself the same type of questions. > > André-John > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Sincerely yours and Best Regards, Xie Xiaodong
