Is it safe to to set transaction isolation level to READ_UNCOMMITTED?
No, it is not. HSQLDB supports read-uncommitted isolation only and jBPM exhibits erratic behavior in concurrent processes, particularly in process variables and join nodes. Apart from HSQLDB, jBPM is continuously tested with READ_COMMITTED isolation.
Is there another, safer solution to this problem?
Yes. Try a newer jBPM version. At least one fix has gone towards improving job execution.
Looks like the issue is with having a lot jobs that execute quickly, which results in a lot of inserts and deletes, which then results in a lot of updates to the indexes. Having removed all the indexes in the jbpm_job table has greatly reduced blocking issues, but not eliminated them. Is there anyway to configure jbpm not to delete jobs, but just mark them as complete?
No, but it would make a fine addition. At some point I thought of a configuration switch to delete process instances once they finished, to avoid filling up the database. Along with a switch to not delete jobs and a procedure to clean up old jobs and, optionally, process instances, jBPM would have a complete cleaning solution.