Explicit locking in JPAStorageService

[Cantor, Scott]

On 11/5/15, 10:28 AM, "dev on behalf of Etienne Dysli-Metref" <dev-bounces at shibboleth.net on behalf of etienne.dysli-metref at switch.ch> wrote:


>
>> However the locking code was added before the retry code, so it may
>> not be as necessary anymore.
>
>Or the two combined may produce more lock contention...

Retries don't create the contention, they deal with it when it happens (and if it does, the database has failed to provide the transaction semantics it's supposed to).

When there's a problem with contention, the database isn't taking the lock it should be. There's no application-visible contention with correct locking (assuming our code isn't deadlock-unsafe), just longer wait time. In our scenarios, excepting that issue we fixed with the cleanup code taking too long, the wait time is really insignificant even under load. These are very simple single-row transactions on indexed fields, so the locks aren't held for long.

When the database fails or starts deadlocking, that means it's *not* taking the locks, it's trying to be cute and not take them. That's the behavior the pessimistic option is trying to minimize. Without that option, none of the locking is correct and the database makes the application deal with the consequences. At that point, using an RDBMS is a waste of time, we could just use Berkeley and get faster performance, at the cost of having to do all our own locking.

(Yes, that's not necessarily a bad idea here as an alternative.)

The SP's ODBC plugin had the same issues, and that was the first time in several years I'd really been exposed to databases other than SQL Server. Back then, at least, when you asked it for SERIALIZABLE, you got ACID transactions. I imagine even they've broken that by now, but I don't know.

-- Scott