This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Multithreaded request handling

 
Ranch Hand
Posts: 128
1
jQuery Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

A simple questions I have:

I created a rest service using Spring RestController. When multiple request comes to access this service, how many instances are created for my RestController class?
Options:
A. Single instance created(as spring beans are by default singleton) ans used by threads one by one
B. For each request a new instance created.

Thanks,
Atul
 
Ranch Hand
Posts: 100
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By Default, Only one instance will be created by the application context. If you want multiple per request, you can annotate the bean with
 
Joseph Mokenela
Ranch Hand
Posts: 100
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joseph Mokenela wrote:By Default, Only one instance will be created by the application context. If you want multiple per request, you can annotate the bean with



Edit: I was meaning to say a new instance per request...instead of multiple.
 
Sheriff
Posts: 21802
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Atul More wrote:Options:
A. Single instance created(as spring beans are by default singleton) ans used by threads one by one
B. For each request a new instance created.


C. Single instance created which will handle multiple requests concurrently. So make sure it's thread safe. If you don't use any custom state but only use Spring's own mechanisms (or JPA) you're safe.
 
Bartender
Posts: 1040
18
Mac OS X IntelliJ IDE Oracle Spring VI Editor Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you really must then the @Async tag, but I'm not sure you need this.  Creating Asynchronous Methods

To quote one of the old clever programmers;
"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." [Donald Knuth].
 
Atul More
Ranch Hand
Posts: 128
1
jQuery Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

As per my understanding,

Single instance created which will handle multiple requests concurrently.



Is it right?

Thanks,
Atul
 
Saloon Keeper
Posts: 10649
227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, but I'm sure there is some way to configure it.
 
Saloon Keeper
Posts: 21122
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Web applications are not "programs" in the sense of being independent free-running processes. Instead they function more like DLLs.

When a web request comes in, the appserver analyzes the request to determine its characteristics, which includes figuring out which of possibly several webapps are deployed in the system. The request itself appears as data structures, but they are all bound together and attached to a Thread pulled from the server's application Thread pool. This Thread then invokes the servlet (or compiled JSP) that corresponds to the request URL by calling its service() method, which often delegates to HttpServlet doGet, doPut, etc., and in the case of Spring, to Spring's own dispatcher servlet code.

So it's absolutely essential that all logic in the chain that handles web requests must be Thread-safe. And, as a reminder, the dispatched Threads themselves are forbidden by the JEE spec from spawning child Threads. So there's only one Thread per Request, but possibly many concurrent Requests.

To avoid this, you should work as much as possible with objects that are unique to the current process. As a common example, each user session (HttpSession) contains the JEE Session-scope objects. This keeps them safe from other user's processing Threads, although not from multiple concurrent requests from the same user. This last problem isn't usually a problem, since generally only one Http request in a cluster is doing heavy logic and the rest are typically just copying CSS, javascripts and other static content their respective response streams. A typical web client may actually run 10-15 or more such requests in parallel.

Another potential, but usually not practical problem is when a request processor handles database operations. As long as the concurrent operations are working with data from distinct bean instances, good database transaction management will take care of the rest. Note that the master processor logic bean(s) can be singletons, it's just the data beans (which are often session- and/or request-scope objects) that need to be thread-safe.

This perhaps isn't be most lucid explanation I've ever made of what the concurrency aspects of web processing are, but I hope it helped.

One final note, however: the best way to get into serious trouble when processing web requests is to store member data in the logic beans. Since the logic beans may be used by multiple threads concurrently, that's begging for trouble. Keep the data out of the logic beans and use the safer session and request scopes for per-user data. Application scope is also not thread-safe, since it's essentially a singleton resource itself.
 
bacon. tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!