Threading in web Application

[Ershad]

I have a Question about Threading In webApplication,
J2ee Support threading! Is it Usefull for web appliction?
if you know php does not support Threading without any problem in web
application

 

[Lew]

I have a Question about Threading In webApplication,
J2ee Support threading! Is it Usefull for web appliction?
if you know php does not support Threading without any problem in web
application

JEE containers are multi-threaded, so generally web apps do "support"
threading, however it is extremely bad practice and a source of multiple bugs
for the web-app developer to explicitly manipulate threads.

It is better to write thread-safe code but not to spawn any threads of your
own, in web-app development.

 

[Daniel Pitts]

JEE containers are multi-threaded, so generally web apps do "support"
threading, however it is extremely bad practice and a source of multiple bugs
for the web-app developer to explicitly manipulate threads.

It is better to write thread-safe code but not to spawn any threads of your
own, in web-app development.

Why is that Lew? Concurrency programming is trickier than serial
programming, but since your webapp is possibly concurrent anyway, you
should learn how that effects your design...

Knowing this, you should also know what is safe to do as far as
spawning your own threads. In general, this means using proper
synchronization constructs, and limiting the number of threads created
so that they don't cause a problem.

There are cases where spawning multiple threads for a single request
make sense. If you have a request that needs to access two separate
high-latency data sources, it makes sense to do them concurrently.

 

[Lew]

Why is that Lew? Concurrency programming is trickier than serial
programming, but since your webapp is possibly concurrent anyway, you
should learn how that effects your design...

Knowing this, you should also know what is safe to do as far as
spawning your own threads. In general, this means using proper
synchronization constructs, and limiting the number of threads created
so that they don't cause a problem.

There are cases where spawning multiple threads for a single request
make sense. If you have a request that needs to access two separate
high-latency data sources, it makes sense to do them concurrently.

I am concerned with the additional difficulties of thread management when the
Web container itself is trying to manage threads. Concurrent programming is
fraught with peril even when the programmer has a measure of control over the
whole process. In a Web container with multiple applications existent
ignorant of each other, and its own thread policies, small mistakes can have
devastating consequences.

I'm sure it's possible and even occasionally useful to explicitly spawn
threads in a web container environment, but there is much more care needed not
to interfere with what the web container does. A badly managed thread could
damage not only the application that spawned it but every application running
on the server.

Your example seems to imply a limited context where threads are born and die
within the handling of a single request. There the risks are much more
contained, and an error-free implementation seems easier. For such a thing I
can see a smart programmer making good use of the idiom, but it isn't
something to abuse or take lightly.

I would never make a blanket statement about never doing something.

 

[Wojtek]

Lew wrote :

I am concerned with the additional difficulties of thread management when the
Web container itself is trying to manage threads. Concurrent programming is
fraught with peril even when the programmer has a measure of control over the
whole process. In a Web container with multiple applications existent
ignorant of each other, and its own thread policies, small mistakes can have
devastating consequences.

Only if my thread in some way interacts with the web container threads.
If the threads I kick off are "self contained" within my code context,
then having threads does not impact the web container.

I have several housekeeping threads which live in the application
object.

I'm sure it's possible and even occasionally useful to explicitly spawn
threads in a web container environment, but there is much more care needed
not to interfere with what the web container does. A badly managed thread
could damage not only the application that spawned it but every application
running on the server.

Your example seems to imply a limited context where threads are born and die
within the handling of a single request. There the risks are much more
contained, and an error-free implementation seems easier. For such a thing I
can see a smart programmer making good use of the idiom, but it isn't
something to abuse or take lightly.

Consider a request which takes a long time to process, say over 2
minutes. Within that time period, most browsers will time out. The user
sees the time out, and re-tries the request. Now TWO processes are
running this long request.

OTOH, the first request could spawn a thread to do the work, place it
in the session, then return to the user. Each request after that checks
to see if the thread has finished, and if so re-directs the user to the
result.