There are a couple of scenarios: removeJob and getTimerByName, where, in case the "persistent cache" mechanism is not in place (which might happen after proess migration), a linear search (in fact, a quadratic search if we took into account that EJB timer subsystem perform another search for the info field) is performed to try to find out a timer reference which is unclear do really exist (so the worst case scenario, loading all timers instances is a real possibility)
This timer search is performed to cancel the timer in the case of job removal (typically a consequence of another error) or to avoid creating a new one in the case of kie session unmarhsalling (although the later can be disabled, doing so has as consequence a very real chance that the bpmn timer is never notified, affecting system behaviour).
 Therefore, the consequence of not performing this linear search is the possibility of having stale entries into EJB timer table, but those stales entries are not really associated with a bpmn timer, so they will be trigger with not functional consequence (there is a potential performance cost in the EJB subsystem, though)
Since, when the number of timers is large, the consequence of performing the linear search are more severe than leaving timers behind, we feel it is better to disable the linear search, print a warning for the timers potentially leaked, and, if they constitute an issue, eventually create a manual tool (with a different JIRA), feed by the logs, to remove them in an efficient way (the manually invoked tool will be allowed to assume some internal of EJB timer subsystem than the platform code cannot do)
In order to decide to enable/disable that linear search, two properties has been added

1. org.jbpm.ejb.timer.disable.linear.search
2. org.jbpm.ejb.timer.disable.linear.remove

By default their value is false. If users want to disable linear seach for getTimerByName, it should set the first one to true. If user want to disable the linear search for removeJob, it should set the second one to true