eXtremeDB locking
来源:互联网 发布:sql中表中能套表吗 编辑:程序博客网 时间:2024/05/04 00:40
Locking optimization
eXtremeDB uses two kinds of synchronization primitives - latches and locks. The
first kind (latch) is a lightweight lock implemented with atomic instructions. It is
used, for example, in btree indexes to lock branches. The second kind (lock) is a
full size synchronization primitive implemented with kernel-locks (and/or
lightweight atomics for performance, if possible). One lock is used for the
eXtremeDB registry and database header, but all other locks applied during
transaction processing depend on the choice of Transaction Manager:
MVCC - multiple latches in indexes, multiple latches/locks in transaction
processing.
MURSIW – no latches in indexes, multiple latches/locks (but fewer than
MVCC) in transaction processing.
EXCLusive - no latches in indexes, one single lock on the transaction queue.
For single-threaded and single-process applications, it is possible to eliminate
latches and locks completely by employing the EXCLusive Transaction Manager
and/or “hollow” synchronization implementation. (A sample “hollow”
synchronization implementation that makes no kernel calls nor atomic operations
or spinlocks is provided as a template for custom user-defined synchronization in
the file mcosempty.c located in the target/sync subdirectory.)
The developer has complete choice regarding the transaction manager and lock
implementations by selecting the transaction manager and synchronization
implementation libraries. Most likely the choice will be between MURSIW and
MVCC based on the characteristics of the application. For applications having
mostly read-only transactions with occasional updates, MURSIW may be the best
choice. If there are a relatively high number of concurrent processes/threads
attempting to modify the database at the same time, then MVCC will probably be
the better choice. If the application is single-threaded, concurrency is not an issue
and clearly it will perform best with the EXCLusive transaction manager or by
simply including the mcosempty.c file in the project and no synchronization
library (see the Release Notes for a more details on synchronization libraries).
eXtremeDB uses two kinds of synchronization primitives - latches and locks. The
first kind (latch) is a lightweight lock implemented with atomic instructions. It is
used, for example, in btree indexes to lock branches. The second kind (lock) is a
full size synchronization primitive implemented with kernel-locks (and/or
lightweight atomics for performance, if possible). One lock is used for the
eXtremeDB registry and database header, but all other locks applied during
transaction processing depend on the choice of Transaction Manager:
MVCC - multiple latches in indexes, multiple latches/locks in transaction
processing.
MURSIW – no latches in indexes, multiple latches/locks (but fewer than
MVCC) in transaction processing.
EXCLusive - no latches in indexes, one single lock on the transaction queue.
For single-threaded and single-process applications, it is possible to eliminate
latches and locks completely by employing the EXCLusive Transaction Manager
and/or “hollow” synchronization implementation. (A sample “hollow”
synchronization implementation that makes no kernel calls nor atomic operations
or spinlocks is provided as a template for custom user-defined synchronization in
the file mcosempty.c located in the target/sync subdirectory.)
The developer has complete choice regarding the transaction manager and lock
implementations by selecting the transaction manager and synchronization
implementation libraries. Most likely the choice will be between MURSIW and
MVCC based on the characteristics of the application. For applications having
mostly read-only transactions with occasional updates, MURSIW may be the best
choice. If there are a relatively high number of concurrent processes/threads
attempting to modify the database at the same time, then MVCC will probably be
the better choice. If the application is single-threaded, concurrency is not an issue
and clearly it will perform best with the EXCLusive transaction manager or by
simply including the mcosempty.c file in the project and no synchronization
library (see the Release Notes for a more details on synchronization libraries).
- eXtremeDB locking
- 关于extremedb
- eXtremeDB-64
- eXtremeDB XML
- eXtremeDB 3.1
- eXtremeDB ODBC
- eXtremeDB pagination
- eXtremeDB 数据类型
- extremedb--calc
- locking.c
- Scoped Locking
- Strategized Locking
- Record locking
- xv6 locking
- eXtremeDB产品概述
- eXtremeDB 基本操作
- eXtremeDB初步调试
- eXtremeDB Memory management
- eXtremeDB XML
- 菜鸟的spring 3.0源码学习之旅(4)
- 菜鸟的spring 3.0源码学习之旅(5)
- Delphi6函数大全(1)
- 菜鸟的spring 3.0源码学习之旅(6)
- eXtremeDB locking
- Rar in mac的安装
- /Documentation/usb/URB.txt
- 完全卸载oracle11g步骤
- Android 大分辨率 问题.(supports-screens)
- RAID 介绍
- 【交互】MFC窗口位置分析
- 最小生成树-prime算法
- 自己最近写的一些c语言的串的算法