Xie Xiaodong wrote: > 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.
That is a massive over complication for this use case. >> On 7-May-2009, at 19:05, David Kerber wrote: >>> 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, You should be able to easily write the decryption (if it isn't already) in a multi-threaded manner. >>> send a small acknowledgement response back to the site, Unlikely to have sync issues (but check to be sure) >>> and write the line to the log file. If you are using a logging framework (like log4j) this will handle the necessary sync for you. Otherwise you may have to write it yourself. Incrementing the counters you are using needs to be synchronized. The simplest solution would be to use atomics. >>> Does that sound like something that would need to be >>> synchronized? So, some bits do must most don't. Getting rid of unnecessary syncs is a good thing but you really should find out where the bottleneck is before you start changing code. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
