Mark Thomas wrote:
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.
That was my thought as well, but I don't know enough about the subject
of concurrency and synchronization to be sure.
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.
To that end, am I correct in understanding that any variables and
objects that are declared locally to the method that does the work (such
as the decryption routine) are going to be inherently thread safe? And
that variables and objects declared at the class level (such as my
counters) may not be? That's what the reading I did last night seemed
to indicate, without explicitly stating so.
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.
I'm doing it with the standard text file methods, but all the objects
and variables are local to the method that processes the request.
Incrementing the counters you are using needs to be synchronized. The simplest
solution would be to use atomics.
I had never heard of them before I was reading about this yesterday, but
it looks like a good possibility.
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.
That's my goal, but as far as I can tell right now, the bottleneck is
narrowed down to either my code, or the customer's network, and testing
some fixes to my code is pretty easy.
Thanks for the comments!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
