Steve, do you anticipate being able to find a middle ground with the locking issue? I just updated my hibernate installation and noticed follow-on locking is used exclusively. I rely on pessimistic locking in the database for a number of projects so I've temporarily overridden useFollowOnLocking() to return false in my own Oracle dialect class. While FOR UPDATE can't be specified for any statement that has a lower-bound result limit and an order by, it should function in all other existing cases. So an upper-bound result limit (firstResult == 0 with maxResults set) with an ORDER BY works just fine:

SELECT ... FROM ... WHERE rownum <= :maxResults ORDER BY ... FOR UPDATE;

Obviously Hibernate now wraps the entire query once either firstResult or maxResults is set, but it's not strictly necessary. Adding this special case for firstResult == 0 would allow immediate pessimistic locking on any use case that said, "give me the earliest/latest/lowest/greatest X and lock them immediately", which happens to match my case perfectly (a task queue with many nodes pulling the "next available task" from the task table--causes optimistic lock failures with follow-on locking).