Subject | FW: [Firebird-devel] IB/FB Lock manager failures |
---|---|
Author | Dmitry Yemanov |
Post date | 2002-09-15T14:22Z |
Your thoughts, ladies and gentlemen?
-----Original Message-----
From: Nickolay Samofatov [mailto:postmaster@...]
Sent: Sunday, September 15, 2002 2:26 PM
To: firebird-devel@...
Subject: [Firebird-devel] IB/FB Lock manager failures
Hello !
We all know that SuperServer engine is inacceptable for doing most serious
tasks, because:
1) It doesn't execute requests in parallel
2) It doesn't support SMP (all common computers will be SMP soon with
HyperThreading)
3) Server failure terminates all user queries
While doing lock manager rework to solve "OBJEXT xx IS IN USE" issue I
discovered
that it is much easyer to move lock manager data to shared memory than to
support current
CS lock architecture, witch tends to slow when number of connections grows.
I.e. I allocate shared memory pool protected with some kind of
mutex/spinlock.
Move lock manager data there (as it is represented in SS architecture).
Than move buffer cache there too. This should solve all current CS
architecture problems.
We may drop SS architecture after that or rework it to work like Oracle
Multi-Threaded Server works.
Suggestions ?
Nickolay Samofatov
-----Original Message-----
From: Nickolay Samofatov [mailto:postmaster@...]
Sent: Sunday, September 15, 2002 2:26 PM
To: firebird-devel@...
Subject: [Firebird-devel] IB/FB Lock manager failures
Hello !
We all know that SuperServer engine is inacceptable for doing most serious
tasks, because:
1) It doesn't execute requests in parallel
2) It doesn't support SMP (all common computers will be SMP soon with
HyperThreading)
3) Server failure terminates all user queries
While doing lock manager rework to solve "OBJEXT xx IS IN USE" issue I
discovered
that it is much easyer to move lock manager data to shared memory than to
support current
CS lock architecture, witch tends to slow when number of connections grows.
I.e. I allocate shared memory pool protected with some kind of
mutex/spinlock.
Move lock manager data there (as it is represented in SS architecture).
Than move buffer cache there too. This should solve all current CS
architecture problems.
We may drop SS architecture after that or rework it to work like Oracle
Multi-Threaded Server works.
Suggestions ?
Nickolay Samofatov