Only 48 hours left in the trailboss' kickstarter!

New rewards and stretch goals. CLICK HERE!



  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How to handle the Servlet response  RSS feed

 
Vivekana Gops
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me present this scenario.

There is a request to the Servlet (of course multithreaded not SingleThreadedModel) which requires lookup from two different databases for the same value. Both the looked up values must tally. Else I have to send an error code in response.

The response time requirement is very very stringent.

A suggested algorithm is to spawn two threads and look up both databases possibly simultaneously. Idea is that the response time instead of adding up as x + y, is kept a minimal as largest of (x or y)
Moreover, if the processing-time is long (say>1000ms) during either of these lookups, that thread needs to be timed out and and the other response needs to be sent back.

How would you do this?
Has anybody done this successfully in Production environment?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
spawn two threads and look up both databases possibly simultaneously.


I don't think there is any general answer. The utility of this approach would depend on what these Threads are doing, what the delays are, where the other resources are, etc.

If the delays are all waiting for different machines to answer, sure having a Thread devoted to each query would save time on the server.

Against that advantage, consider the complexity of coordinating gathering the results and providing for all the various error conditions.

Do certain queries occur often enough to justify caching locally?

Bill
 
Vivekana Gops
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bill,

Thanks a lot for your reply.

Yes the delays are all waiting for different machines to answer.

The vision/direction is to take up complexity. However, stability of the application wins over other competing concerns.

Caching is definitely an option in a few cases, but not for all cases.

In those cases where caching is not an option, is it safe to have devoted Threads? The last thing we want is an unstable application.
What is the right way to safely kill these spawned Threads at predefined intervals?
Not done anything like this so far in a web application. Just want to be sure.

Found this: https://groups.google.com/group/comp.lang.java.programmer/msg/0fea9dd5f0117a7f?hl=pt&pli=1

Is this a tried and tested method for web applications / web services?
Would be great to hear back your suggestions.

Vivek



 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In those cases where caching is not an option, is it safe to have devoted Threads? The last thing we want is an unstable application.
What is the right way to safely kill these spawned Threads at predefined intervals?


Lets say you create a new Runnable object for each DB query, create (or assign from a pool) a Thread for each and start them.

If you ensure that there is no way a Thread could get stuck in the run method - due to DB not answering, etc - and will always fall out of the run method no matter what - then that takes care of Threads hanging around. Ensuring that DB connections get cleaned up before exiting the run() under all conditions is essential.

If the request Thread is the only thing holding references to these Runnable objects that should allow them to be GCed properly.

Bill

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!