There are 2 flavors of job executors available - old jobExecutor and modern asyncExecutor. User guide recommends to use asyncExecutor, but for basic needs both can work. Do no try to enable both at the same time though, even on different machines connected to one DB.
Each executor tends to request DB for timer/async/retry jobs. Once jobs are found they are executed in several threads of executor engine environment application.
You have to have all libs, connections and environment bits to execute jobs properly. For example, there is no http request in async job, so if your java delegate somehow looks for http request, you'll be in trouble.
Once executor is enabled, you get job retry behaviour of activity engine. Simple process fails without retries, but async/timer continuation will cause multiple (3 by default) retries with set time intervals. You have to be ready for this.
It's also possible that timer execution will overlap with regular task continuation. You can avoid some "unexpected" issues if you think about this beforehand.
Performance can be an issue if you need hyperspeed of your processes. Each async step slows down the process - its state is saved to DB and then fetched back. Generally job execution "speed" depends on settings for executor timers/threads, something like defaultTimerJobAcquireWaitTimeInMillis, maxPoolSize, maxTimerJobsPerAcquisition, for asyncJobExecutor.
