Engine Changes
Support of Classic Architecture
Changes for 64 bit pointers and record struct additions.
ODS Change
The ODS for InterBase version 5.0 has been updated to support cascading
referential integrity. Databases in ODS 8.0 will be dynamically upgraded to ODS
8.1 when the database is first connected using InterBase version 5.0.
New databases created by v5.0 will be in ODS 9.0. ODS 9.0 supports index
garbage collection and SQL ROLES.
In ODS 9.0 relation numbers 0 .. 127 are reserved for system relations.
(Previously, in ODS 8.x, the first user relation number was 31).
On Windows NT, Win95, Windows 3.1 and Novell - ODS 8.x calculates checksums
for each disk page. (Other platforms do NOT calculate checksums for ODS 8.x).
In ODS 9.0 no checksums are calculated for any platform.
ODS Version vs InterBase Version
IB 4.0, 4.1 and 4.2 create ODS 8.0
IB 5.0 will upgrade an ODS 8.0 to ODS 8.1 which includes changes for cascading
referential integrity.
IB 5.0 creates ODS 9.0 which supports garbage collection for indices with valid
back pointers. ODS 8.X databases are not transparently upgraded to ODS 9.0 - a
database must be backed up and restored to use the new ODS 9.0 features.
V5.0 supports both ODS 8.x and ODS 9.0. There is no bridge used.
SPX Client Support for Windows NT & 95
SPX client support for NT & 95 is not part of the NevaStone
specification. SPX support will be implemented on a post 5.0 kit as and when a
Netware 4.x implementation of Interbase becomes available. The Implementation
will be as follows:
- The Client software will be implemented over WinSock 1.1
- The WinSock 1.1 SAP addressing feature does not work and so SAP addresses
will be resolved by a home grown implementation of parsing raw SAP packets off
the wire.
- InterBase on Netware 3.1 sequences packet fragments over and above the SPX
sequencing. In other words, it appends a sequence as a header on each fragment
and expects the client to parse of the appended header and reconstruct the
packet. This method works fine as long as a Novell Client SDK is used on
Windows. The Novell Client SDK makes the low level fragments visible. This is
how the 16 bit InterBase clients for Windows 3.1 are implemented.
- The new version of InterBase (IB 4.2 on Netware 4.x) needs to continue to
provide this mode of data exchange so as to provide backward compatibility to
existing 16 bit Interbase clients. Additionally, the server needs to? Discard
the use of additional sequencing? when talking to SPX clients for NT & 95.
This is absolutely required as a WinSock client has no access to low level
fragment headers at all.
Remote Protocol Performance
Numerous performance enhancements have been made to the InterBase remote
protocol. The basic protocol is still version 8, but client and server-side
performance has been increased:
- Bugs in the calculation of buffering while doing ESQL & DSQL cursor
fetches have been fixed.
- The Client side now does look-ahead caching of data rows (meaning that the
client will batch fetch data rows from the server before the client-side cache
is exhausted).
As a result of the client-side data caching, there may be a minor increase
in client memory utilization should multiple cursors be active in the
application. Memory Allocation
Memory Allocation
SuperServer will now allocate memory in such a way that it can be released
back to OS instead of the engine's internal heap manager. The initial pass is
to target database buffers and sort buffers to use this mechanism; they are
obvious candidates: A sort buffer is 128Kb and database buffer pools can be
multiple megabytes or potentially gigabytes. The current implementation also
includes memory allocations greater than 256KB. Thus all allocation requests
greater than 256K in the engine will be allocated, and subsequently released
back to the OS.
Lock Management
New parameters in isc_config
V4_SOLARIS_STALL_VALUE - Classic Solaris platforms only.
Solaris is known to be "unfair" to the processes (threads) waiting on
mutexes - with a mutex that is in high contention (such as InterBase lock table
mutex) it is possible for some processes to never manage to acquire the mutex.
To fight this problem we implemented a " fairness" algorithm . In
this algorithm a process (thread) entering the lock table tries to determine if
other processes have been "starved" out of the lock table. If so, the
thread voluntarily releases the lock table and goes to sleep. When the
"starved" process (thread) finally acquires the lock table it does
its work and on exit awakens all the processes that went to sleep due to its
starvation.
This parameter specifies how long a process (thread) should sleep to let the
"starved" process run.
Default: 60 seconds. Minimum: 0. Maximum: 200. To disable the algorithm the
parameter should be set to 0.
LOCK_HASH_SLOT
This parameter specifies a number of hash slots in the lock table. The higher
the parameter the shorter the hash chains. Shorter hash chains result in faster
lock operation and decrease the likelihood that a process will context switch
while owning the lock table mutex. On the other hand more hash slots require
more space in the lock table (101 hash slot cost 800 bytes, a setting of 501
would cost an additional 3200 bytes, but reduce lock hash chains by a factor of
5 approximately).
Default: 101. Minimum: 101. Maximum: 2048.
Changes to existing parameters
V4_LOCK_MEM_SIZE
The parameter specifies the size of the lock table. Default is 96K.
In the Superserver on all platforms and Classic architecture without
MMAP_SUPPORTED the lock table size is not changed (increased) automatically.
User needs to increase the above parameter in isc_config file.
Also, in the SuperServer without MMAP_SUPPORTED a memory segment for the lock
table is allocated exactly of a size specified by the parameter even if a
memory segment of another size with the same key already exists in a system.
The same could be said about V4_EVENT_MEM_SIZE.
Grant/Revoke UNIX group privileges through SQL
Support UNIX group on GRANT/REVOKE statements unix_role. This is a new
feature. In the past, UNIX group privileges could only be granted/revoked
through IB proprietary language called GDML. With this new feature, now user
could grant/revoke UNIX group privileges through SQL GRANT/REVOKE statements.
|
