Feature #18557
closedIntegrate locking by database in t3lib_lock
0%
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
Updated by Steffen Kamper over 16 years ago
+1
this can also be useful if someone edit a record, it can be locked for other users.
Updated by Oliver Hader over 16 years ago
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").
Updated by Oliver Hader over 16 years ago
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'
Updated by Oliver Hader over 16 years ago
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.
Updated by Ernesto Baschny almost 14 years ago
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.
Updated by Björn Pedersen over 13 years ago
related to: http://bugs.typo3.org/view.php?id=16749
Updated by Xavier Perseguers about 13 years ago
- 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
Updated by Xavier Perseguers about 13 years ago
- Target version deleted (
4.6.0-beta1)
Updated by Christian Kuhn almost 13 years ago
I'm unsure if we really need an own table for this. Probably the registry could be used for this, too.
Updated by Ingo Renner almost 13 years ago
I agree, this is a perfect job for the registry...
Updated by Mathias Schreiber over 9 years ago
- Status changed from New to Needs Feedback
Still taking care? ;-)
Updated by Helmut Hummel over 9 years ago
- Status changed from Needs Feedback to Rejected
- Assignee deleted (
Helmut Hummel)
nope
Updated by Susanne Moog over 5 years ago
- 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.
Updated by Benni Mack over 5 years ago
- Status changed from New to Accepted
- Assignee set to Benni Mack
Will take care of this
Updated by Benni Mack over 4 years ago
- Status changed from Accepted to Rejected
We now have an API in place (since TYPO3 v10) to build this properly - otherwise I recommend using "distributed locks" (see https://github.com/b13/distributed-locks)