org.springframework.scheduling

Interface SchedulingTaskExecutor

All Superinterfaces:

AsyncTaskExecutor, Executor, TaskExecutor

All Known Implementing Classes:

ConcurrentTaskExecutor, ConcurrentTaskScheduler, DefaultManagedTaskExecutor, DefaultManagedTaskScheduler, GlassFishWorkManagerTaskExecutor, JBossWorkManagerTaskExecutor, SimpleThreadPoolTaskExecutor, ThreadPoolTaskExecutor, ThreadPoolTaskScheduler, WorkManagerTaskExecutor, WorkManagerTaskExecutor

public interface SchedulingTaskExecutor
extends AsyncTaskExecutor

A TaskExecutor extension exposing scheduling characteristics that are relevant to potential task submitters.

Scheduling clients are encouraged to submit Runnables that match the exposed preferences of the TaskExecutor implementation in use.

Note: SchedulingTaskExecutor implementations are encouraged to also implement the AsyncListenableTaskExecutor interface. This is not required due to the dependency on Spring 4.0's new ListenableFuture interface, which would make it impossible for third-party executor implementations to remain compatible with both Spring 4.0 and Spring 3.x.

Since:

2.0

Author:

Juergen Hoeller

See Also:

SchedulingAwareRunnable, TaskExecutor, WorkManagerTaskExecutor

Field Summary

Fields inherited from interface org.springframework.core.task.AsyncTaskExecutor

TIMEOUT_IMMEDIATE, TIMEOUT_INDEFINITE

Method Summary

Modifier and Type	Method and Description
boolean	prefersShortLivedTasks() Does this TaskExecutor prefer short-lived tasks over long-lived tasks?

Methods inherited from interface org.springframework.core.task.AsyncTaskExecutor

execute, submit, submit

Methods inherited from interface org.springframework.core.task.TaskExecutor

execute

Method Detail

prefersShortLivedTasks

boolean prefersShortLivedTasks()

Does this TaskExecutor prefer short-lived tasks over long-lived tasks?

A SchedulingTaskExecutor implementation can indicate whether it prefers submitted tasks to perform as little work as they can within a single task execution. For example, submitted tasks might break a repeated loop into individual subtasks which submit a follow-up task afterwards (if feasible).

This should be considered a hint. Of course TaskExecutor clients are free to ignore this flag and hence the SchedulingTaskExecutor interface overall. However, thread pools will usually indicated a preference for short-lived tasks, to be able to perform more fine-grained scheduling.

Returns:

true if this TaskExecutor prefers short-lived tasks