Spring 2.0 introduces a new abstraction for dealing with executors. Executors are the Java 5 name for the concept of thread pools. The "executor" naming is due to the fact that there is no guarantee that the underlying implementation is actually a pool; an executor may be single-threaded or even synchronous.
Spring's abstraction hides implementation details between Java SE 1.4, Java SE 5 and Java EE environments.
Spring's TaskExecutor interface is identical to the java.util.concurrent.Executor interface. In fact, its primary reason for existence is to abstract away the need for Java 5 when using thread pools. The interface has a single method execute(Runnable task) that accepts a task for execution based on the semantics and configuration of the thread pool.
The TaskExecutor was originally created to give other Spring components an abstraction for thread pooling where needed. Components such as the ApplicationEventMulticaster, JMS's AbstractMessageListenerContainer, and Quartz integration all use the TaskExecutor abstraction to pool threads. However, if your beans need thread pooling behavior, it is possible to use this abstraction for your own needs.
There are a number of pre-built implementations of TaskExecutor included with the Spring distribution. In all likelihood, you shouldn't ever need to implement your own.
This implementation does not reuse any threads, rather it starts up a new thread for each invocation. However, it does support a concurrency limit which will block any invocations that are over the limit until a slot has been freed up. If you're looking for true pooling, keep scrolling further down the page.
This implementation doesn't execute invocations asynchronously. Instead, each invocation takes place in the calling thread. It is primarily used in situations where multithreading isn't necessary such as simple test cases.
This implementation is a wrapper for a Java 5 java.util.concurrent.Executor. There is an alternative, ThreadPoolTaskExecutor, that exposes the Executor configuration parameters as bean properties. It is rare to need to use the ConcurrentTaskExecutor but if the ThreadPoolTaskExecutor isn't robust enough for your needs, the ConcurrentTaskExecutor is an alternative.
This implementation is actually a subclass of Quartz's SimpleThreadPool which listens to Spring's lifecycle callbacks. This is typically used when you have a thread pool that may need to be shared by both Quartz and non-Quartz components.
It is not possible to use any backport or alternate versions of the java.util.concurrent package with this implementation. Both Doug Lea's and Dawid Kurzyniec's implementations use different package structures which will prevent them from working correctly.
This implementation can only be used in a Java 5 environment but is also the most commonly used one in that environment. It exposes bean properties for configuring a java.util.concurrent.ThreadPoolExecutor and wraps it in a TaskExecutor. If you need something advanced such as a ScheduledThreadPoolExecutor, it is recommended that you use a ConcurrentTaskExecutor instead.
This implementation uses a single TimerTask as its backing implementation. It's different from the SyncTaskExecutor in that the method invocations are executed in a separate thread, although they are synchronous in that thread.
CommonJ is a set of specifications jointly developed between BEA and IBM. These specifications are not Java EE standards, but are standard across BEA's and IBM's Application Server implementations.
This implementation uses the CommonJ WorkManager as its backing implementation and is the central convenience class for setting up a CommonJ WorkManager reference in a Spring context. Similar to the SimpleThreadPoolTaskExecutor, this class implements the WorkManager interface and therefore can be used directly as a WorkManager as well.
Using a TaskExecutor
Spring's TaskExecutor implementations are used as simple JavaBeans. In the example below, we define a bean that uses the ThreadPoolTaskExecutor to asynchronously print out a set of messages.import org.springframework.core.task.TaskExecutor;
As you can see, rather than retrieving a thread from the pool and executing yourself, you add your Runnable to the queue and the TaskExecutor uses its internal rules to decide when the task gets executed.
To configure the rules that the TaskExecutor will use, simple bean properties have been exposed.<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
Java-Springs Related Interview Questions
|Adv Java Interview Questions||J2EE Interview Questions|
|Core Java Interview Questions||JSP Interview Questions|
|Java-Springs Interview Questions||Java Servlets Interview Questions|
|JMS(Java Message Service) Interview Questions||Hibernate Interview Questions|
|Java applet Interview Questions||Java Interview Questions|
|Framework7 Interview Questions||Java collections framework Interview Questions|
|Java 8 Interview Questions||Java Programmer Interview Questions|
Introduction To Spring Framework
New Features And Enhancements In Spring 3.0
The Ioc Container
Validation, Data Binding, And Type Conversion
Spring Expression Language (spel)
Aspect Oriented Programming With Spring
Spring Aop Apis
Data Access With Jdbc
Object Relational Mapping (orm) Data Access
Marshalling Xml Using O/x Mappers
Web Mvc Framework
Integrating With Other Web Frameworks
Portlet Mvc Framework
Remoting And Web Services Using Spring
Enterprise Javabeans (ejb) Integration
Jms (java Message Service)
Task Execution And Scheduling
Dynamic Language Support
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.