Explicit locking in JPAStorageService

[Etienne Dysli-Metref]

On 05/11/15 00:28, Cantor, Scott wrote:
> 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.

My DBA colleagues would disagree. ;)

> 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.

So this retry logic is only there in case locking doesn't work as you
expect?

> 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.

I don't know what the ISO/IEC SQL standard says, since it is not freely
available, but locking a whole table seems excessive where a range lock
would suffice.

One could also set the isolation level on the JDBC DataSource, but then
it would apply to all transactions and JPA doesn't provide a way to
override it.

  Etienne

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20151105/bab838be/attachment.sig>