AnsweredAssumed Answered

Putting Job(/Message/Timer)Entity on queue instead of jobId

Question asked by ronald.van.kuijk on Jan 11, 2011
Latest reply on Jan 11, 2011 by ronald.van.kuijk
I'm thinking about one more optimization regarding the JobExecutor related to reducing the number of queries. Currently when a job is excecuted, it is retrieved from the DB based on its id. I did not find any caching for this. So we could do two things.
- Create some caching mechanism (not sure MyBatis has some kind of second level cache that you can turn on selectively
- Putting the entity in the queue instead of the id.

If this is in effect, it would have reduced the number of queries for the job executor under normal circumstances from 1 big query to retrieve all jobs and 2 selects and 2 updates PER JOB to just one update per job (if it is a cache hit). I've already tried putting the job in the queue and this works, but there might be downsides to this that I do not know of (since I do not know MyBatis that well and the doc mostly points to older versions, A JPA persistency layer anyone? Would be a nice challenge for me :-))

Thoughts?

Outcomes