Explicit locking in JPAStorageService

[Cantor, Scott]

On 11/4/15, 6:10 PM, "dev on behalf of Daniel Fisher" <dev-bounces at shibboleth.net on behalf of dfisher at vt.edu> wrote:



> Could someone explain the rationale behind
>requesting specific lock types instead of, for example, letting the
>database decide which locking level is appropriate for a query?

Yes, it's quite simple. The databases are broken. They don't always even provide pessimistic locking, in fact, which is the reason for the retry logic being necessary.

Without the proper lock, the retry logic will kick in much more often and fail much more often, under load. The SP code has proven that.

>As I recall the databases we tested didn't do a good job of selecting the correct lock[1].
>However the locking code was added before the retry code, so it may not be as necessary anymore.

Oracle doesn't give you pessimistic locking, it's really as simple as that. If a standard select without auto-commit on under SERIALIZABLE doesn't take a table lock, the database is non-compliant. Most are. It's a sad state of affairs.

A lot of them use a non-standard SQL syntax to specify a table lock, but that's not a solution for portable code.

-- Scott