CRM_Core_Lock
class CRM_Core_Lock implements LockInterface
Constants
| TIMEOUT |
|
Properties
| static bool | $jobLog | This variable (despite it's name) roughly translates to 'lock that we actually care about'. | |
| protected | $_hasLock | ||
| protected | $_name | ||
| protected | $_id |
Methods
Use MySQL's GET_LOCK(). Locks are shared across all Civi instances on the same MySQL server.
Use MySQL's GET_LOCK(), but apply prefixes to the lock names.
Use MySQL's GET_LOCK(), but conditionally apply prefixes to the lock names (if civimail_server_wide_lock is disabled).
Initialize the constants used during lock acquire / release
No description
Acquire lock.
No description
No description
No description
CRM-12856 locks were originally set up for jobs, but the concept was extended to caching & groups without understanding that would undermine the job locks (because grabbing a lock implicitly releases existing ones) this is all a big hack to mitigate the impact of that - but should not be seen as a fix. Not sure correct fix but maybe locks should be used more selectively? Or else we need to handle is some cool way that Tim is yet to write :-) if we are running in the context of the cron log then we would rather die (or at least let our process die) than release that lock - so if the attempt is being made by setCache or something relatively trivial we'll just return TRUE, but if it's another job then we will crash as that seems 'safer'
Details
at line 70
static LockInterface
createGlobalLock(string $name)
Use MySQL's GET_LOCK(). Locks are shared across all Civi instances on the same MySQL server.
at line 86
static LockInterface
createScopedLock(string $name)
Use MySQL's GET_LOCK(), but apply prefixes to the lock names.
Locks are unique to each instance of Civi.
at line 103
static LockInterface
createCivimailLock(string $name)
deprecated
deprecated
Use MySQL's GET_LOCK(), but conditionally apply prefixes to the lock names (if civimail_server_wide_lock is disabled).
at line 125
__construct(string $name, int $timeout = NULL, bool $serverWideLock = FALSE)
Initialize the constants used during lock acquire / release
at line 144
__destruct()
at line 178
bool
acquire(int|NULL $timeout = NULL)
Acquire lock.
The advantage of mysql locks is that they can be used across processes. However, only one can be used at once within a process. An attempt to use a second one within a process prior to mysql 5.7.5 results in the first being released.
The process here is 1) first attempt to grab a lock for a mailing job - self::jobLog will be populated with the lock id & a mysql lock will be created for the ID.
If a second function in the same process attempts to grab the lock it will enter the hackyHandleBrokenCode routine which says 'I won't break a mailing lock for you but if you are not a civimail send process I'll let you pretend you have a lock already and you can go ahead with whatever you were doing under the delusion you have a lock.
at line 211
bool|null|string
release()
at line 231
bool|null|string
isFree()
at line 240
bool
isAcquired()
at line 257
bool
hackyHandleBrokenCode(string $jobLog)
CRM-12856 locks were originally set up for jobs, but the concept was extended to caching & groups without understanding that would undermine the job locks (because grabbing a lock implicitly releases existing ones) this is all a big hack to mitigate the impact of that - but should not be seen as a fix. Not sure correct fix but maybe locks should be used more selectively? Or else we need to handle is some cool way that Tim is yet to write :-) if we are running in the context of the cron log then we would rather die (or at least let our process die) than release that lock - so if the attempt is being made by setCache or something relatively trivial we'll just return TRUE, but if it's another job then we will crash as that seems 'safer'