-
Bug
-
Resolution: Done
-
Major
-
10.1.0.Final
-
None
https://issues.redhat.com/browse/ISPN-10337 Added the FOR UPDATE to the select query used by the purge method in order to ensure that the purge method would lock all of the affected rows so that no subsequent updates to a key could be incorrectly removed by the purge method.
However, if the purge does a select for update and does a single commit at the end of the purge, that will block write operations on all the expired keys for the entire duration of the purge. The clustered purge listener does cache.removeLifespanExpired(key, null, null).join(), so the entire duration of the purge could mean a really long time.
Instead we should utilise a normal select query followed by a 'delete from table where id = ? and timestamp = ?' to prevent accidentally deleting an update.
- is duplicated by
-
ISPN-13932 Reproducible Socket read timed out error while performing expiration on jdbc cache store.
- Resolved
- is related to
-
ISPN-13487 Deadlock in JDBC Store expiration
- Resolved
- relates to
-
ISPN-10337 JDBC Purge consistency issues
- Closed