0

We learn from the beginning that, thread is use to make parallel processing, but later when it come to web application development some suggest to never use thread in web application. i.e We have Checkmarx scanner and that suggest us to not thread in web application.

Base on our application architecture - we have design where on page load, control bind data from database.

Now assume we have 5 DropDownList and all are binding data from database, and for that we create thread so overall it take less time compare to sequential binding (NOTE: We join all thread at the end of event).

So my doubt is should we use thread in web application. If yes then in which manner as thread safety is major issue. And no then why?

from below link I get some information.

Is it not encouraged to use threads in web application?

role of multithreading in web application

Community
  • 1
  • 1
Sagar Upadhyay
  • 35
  • 2
  • 4
  • I'm voting to close this question as off-topic because **is it good/best to do XXX** is opinion based and highly specific to a given scenario there is no general rule and it is too broad as well. If you have to ask a question like this you will probably do more harm than good. –  Jul 12 '15 at 09:51
  • 1
    When someone suggests not to use threads I tend to ignore him cause he has no idea what he is talking about. – freakish Jul 12 '15 at 09:53

2 Answers2

3

Spawning threads inside a web application is always a tricky. Threads come at a high cost (instantiation and system resources), they can hang, they must be managed, if too many threads are spawned it can crash the system. Furthermore, web application page can be invoked hundreds of times concurrently.

I always answer this from context because i do not think threads are evil. If a web application developer asks me: Should he spawn five threads inside the server for each client invocation for five drop downs? I answer: NO, of course not! That sounds like a web application made for ten users concurrently!

Where I would say yes: You have implemented a service-side REST API. All your drop downs need input from different REST services. I would say, yes, let yourself loose fire all AJAX-Request up! The client can handle it, he does not have to manage hundreds of users. Your server will still look good.

Threads are not the problem. The application of threads can be a problem. Build a simple prototype of your idea and then use a load balancing app to invoke your page. Use a hundred user concurrently doing 1000 calls. Monitor the system and see what your threading does to your system. If it improves then use it, if it crashes do not use it. Collect experiences and apply threading accordingly.

blacklabelops
  • 4,708
  • 5
  • 25
  • 42
  • 1
    Looks like a formal definition of what I wrote in my first paragraph. – blacklabelops Jul 12 '15 at 11:08
  • Looks at this post for JavaEE threading: LEGALLY STARTING THREADS/SYNCHRONIZING EJBS - HELL OR HEAVEN: http://www.adam-bien.com/roller/abien/entry/legally_starting_threads_in_ejbs. "Starting and managing threads in the application code is hard to implement, monitor and debug - it is by no means a best practice." - It does not mean it's forbidden. – blacklabelops Jul 12 '15 at 11:16
0

I think multi-threading depends on its usage and frequency. For example, if your 5 dropdown list binding database are used once a day, there is no reason to prevent you from using multi-threads. However, if your dropdown list are created for each request and you have 1k requests per min, parallel computing will overload your cores and the queuing time will be much higher than sequencial processing.

Kun
  • 21
  • 2