Feature #18557

Integrate locking by database in t3lib_lock

Added by Oliver Hader over 11 years ago. Updated 6 months ago.

Status:
Accepted
Priority:
Should have
Assignee:
Category:
Locking / Session Handling
Target version:
-
Start date:
2008-04-03
Due date:
% Done:

0%

PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

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)

oracle__typo3_dbLock.zip (933 Bytes) Administrator Admin, 2008-04-03 18:08

0008010.patch View (4.71 KB) Administrator Admin, 2008-04-03 18:14

0008010_v2.patch View (2.9 KB) Administrator Admin, 2008-04-21 14:43

0008010_v3.patch View (4.12 KB) Administrator Admin, 2010-07-21 16:40


Related issues

Related to TYPO3 Core - Bug #24342: t3lib_lock still sometimes has a race condition on deleting locks. Closed 2010-12-15

History

#1 Updated by Steffen Kamper over 11 years ago

+1
this can also be useful if someone edit a record, it can be locked for other users.

#2 Updated by Oliver Hader over 11 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").

#3 Updated by Oliver Hader over 11 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'

#4 Updated by Oliver Hader over 11 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.

#5 Updated by Ernesto Baschny about 9 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.

#7 Updated by Xavier Perseguers over 8 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

#8 Updated by Xavier Perseguers about 8 years ago

  • Target version deleted (4.6.0-beta1)

#9 Updated by Christian Kuhn almost 8 years ago

I'm unsure if we really need an own table for this. Probably the registry could be used for this, too.

#10 Updated by Ingo Renner almost 8 years ago

I agree, this is a perfect job for the registry...

#11 Updated by Helmut Hummel almost 8 years ago

  • Assignee set to Helmut Hummel

I take care of this

#12 Updated by Mathias Schreiber almost 5 years ago

  • Status changed from New to Needs Feedback

Still taking care? ;-)

#13 Updated by Helmut Hummel almost 5 years ago

  • Status changed from Needs Feedback to Rejected
  • Assignee deleted (Helmut Hummel)

nope

#14 Updated by Susanne Moog 6 months 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.

#15 Updated by Benni Mack 6 months ago

  • Status changed from New to Accepted
  • Assignee set to Benni Mack

Will take care of this

Also available in: Atom PDF