Just a note, switching to java7 fixes this.

In applyLocksToSql(), the locks iterator from LockOptions is based off the entrySet() of a HashMap. My sql looks something like this:

... from IMPORT_STG_MASTER importstag0_ inner join COMPANY company1_ ...

When replacing the aliases with the lockHint, the iterator returns them the aliases in the order:

comany1_
importstag0_

After replacing for company the sql looks like this:

... from IMPORT_STG_MASTER importstag0_ inner join COMPANY company1_ with (updlock, rowlock) ...

and the correction is now 24. Because the second alias will be found at a position before the first one and because the correction is added to the start position, the replacement is done at an invalid position. After the second replacement my sql looks like this:

... from IMPORT_STG_MASTER importstag0_ inner join importstag0_ with (updlock, rowlock)any1_ with (updlock, rowlock) on ...

Causes:
a) the lookup for the aliases is done on the initial sql string; needs a correction
b) the hashmap of lock options does not guarantee order of aliases return by the iterator, so if the second alias is found before the first if will replace ar an incorrect position

Solutions:
a) implement some ordering of the aliases so they get applied left to right
b) do the lookup for the alias directly on buffer (StringBuilder)