Feature #18557
closed
Integrate locking by database in t3lib_lock
Added by Oliver Hader over 16 years ago.
Updated over 4 years ago.
Category:
Locking / Session Handling
Description
In environments with more than one webserver, locking on using the filesystem might not be a good idea since synchronisation of those information is too slow. A possibility is to use the database storage for locking.
This issue is not about database transactions but more about storing a locking semaphore in the database.
A new locking mode besides simple, flock, semaphore and disable shall be integrated: <b>database</b>
(issue imported from #M8010)
Files
+1
this can also be useful if someone edit a record, it can be locked for other users.
I attached an intial version (experimental and not much tested).
Since the patch extends the TYPO3_DB object, also DBAL should be envolved in using these locks. A "typo3_dbLock" package for Oracle is attached (thanks a lot to "Sigi").
MySQL's GET_LOCK() is a no-go. The following "locking" in one process will release the first lock:
SELECT GET_LOCK('lock1', 10);
SELECT GET_LOOK('lock2', 20); --> releases 'lock1'
The new patch creates a sys_lock table which holds these locks.
When the database hammers/polls if a lock is active, the information will come from the database cache until the lock is released or changed.
I see no other possibility to implement such a lock for a concurrent scenario.
Sounds great, Olly. Any way to test or use this kind of locking?
Currently I only see the page generation using t3lib_lock in the core. It's type can be set using ['SYS']['lockingMode'], which defaults to 'simple'.
Maybe we can introduce the new DB based locking to the core and test it using that lock? And later on we can make use of it for other situations.
- Category deleted (
Communication)
- Status changed from Accepted to New
- Assignee deleted (
Oliver Hader)
- Target version changed from 4.6.0 to 4.6.0-beta1
- Target version deleted (
4.6.0-beta1)
I'm unsure if we really need an own table for this. Probably the registry could be used for this, too.
I agree, this is a perfect job for the registry...
- Assignee set to Helmut Hummel
- Status changed from New to Needs Feedback
- Status changed from Needs Feedback to Rejected
- Assignee deleted (
Helmut Hummel)
- Category set to Locking / Session Handling
- Status changed from Rejected to New
The feature would still be nice (now on the new locking strategy framework) to provide cluster compatible locking ootb.
- Status changed from New to Accepted
- Assignee set to Benni Mack
- Status changed from Accepted to Rejected
Also available in: Atom
PDF