@title [筆記]事務(wù)處理
#1 Transaction Propagation Behavior
Required:Excute within a current tx, create a new one if none exists.
Supports: Excute within a current tx, execute without a tx if none exsits.
Mandatory: Excute within a current tx, throw an exception if none exists.
Requires New: Create a new tx and excute within the tx, suspend the current tx if one exists.
Not Supported: Excute without a tx, suspend the current tx if none exsits.
Never: Excute without a tx, throw an exception if a tx exsits.
#2 Transaction Isolation Level[1]
#2.1 Concurrent Problem
Dirty Reads: 臟讀(臟數(shù)據(jù)指已更新,還沒提交的數(shù)據(jù))。事務(wù)T1讀取到事務(wù)T2中的臟數(shù)據(jù)。
Unrepeatable Reads: 不可重復(fù)讀。事務(wù)T1檢索到某行后,事務(wù)T2更新并提交了該行,若事務(wù)T2再次檢索該行,則會(huì)看到不一樣的結(jié)果。
Phantom Reads: 虛讀。事務(wù)T1檢索到符合某條件的行集后,事務(wù)T2插入并提交了滿足該條件的新行,若事務(wù)T2再次按該條件檢索,則會(huì)看到以前不存在的行“Phantom”。
#2.2 Isolation Level
+---------------+-------+------------------+-----------+
|Isolation Level|Phantom|Unrepeatable Reads|Dirty Reads|
+---------------+-------+------------------+-----------+
|Read Uncommited| Y | Y | Y |
+---------------+-------+------------------+-----------+
|Read Commited | Y | Y | N |
+---------------+-------+------------------+-----------+
|Repeatable Read| Y | N | N |
+---------------+-------+------------------+-----------+
|Serializable | N | N | N |
+---------------+-------+------------------+-----------+
#3 Timeout
#4 ReadOnly Transaction
只讀事務(wù)保證了多條查詢SQL的在事務(wù)級別的讀一致性。JDBC和數(shù)據(jù)庫會(huì)對只讀事務(wù)做一些優(yōu)化。
[1] C.J.Date, An Introduction to Database Systems 7th.
iteration::two Cairngorm 0.99 開發(fā)指南
@author sakis
@version 0.1
#0
MXML優(yōu)點(diǎn):使用方便,XML代碼簡潔易懂
缺點(diǎn):事件、函數(shù)、界面描混在一起。程序規(guī)模大了難于開發(fā)維護(hù)。
#1
Cairngorm框架是iterationtwo推出的號稱基于JEE Best Practice的Flex程序開發(fā)的light-weight framework。(恩,light-weight這個(gè)詞還真是流行呢)。目前最新版本為0.99。
Cairngorm的結(jié)構(gòu)如下:
org
└─nevis
└─cairngorm
├─application
│ CairngormApplication.as
│
├─business
│ Responder.as
│ ServiceLocator.as
│
├─commands
│ Command.as
│ SequenceCommand.as
│
├─control
│ Event.as
│ EventBroadcaster.as
│ FrontController.as
│
├─model
│ ModelLocator.as
│
├─view
│ ViewHelper.as
│ ViewLocator.as
│
└─vo
ValueObject.as
#2
下面給大家簡單介紹Cairngorm的實(shí)現(xiàn)思路。
#2.1
Command/FrontController將Event與Viwe分離。
FrontController實(shí)現(xiàn)Singleton模式(以下簡寫為SP)。所有自定義的Command在要在FrontController構(gòu)造函數(shù)中實(shí)例化并以關(guān)聯(lián)數(shù)組的方式注冊FrontController#addCommand(eventType:String, commandInstance:Command)。EventBroadcaster實(shí)現(xiàn)SP。Event類的結(jié)構(gòu)為{type:eventType, data:eventData}。我們通過EventBroadcaster#broadcastEvent(eventType:String, eventData:Object)發(fā)布Event。Event發(fā)布后,與eventType對應(yīng)的command instance執(zhí)行Command#execute(event:Event)。
BTW:在Cairngorm的源碼中,eventType、commandName、eventName混用,我統(tǒng)一用eventType。
#2.2
ServiceLocator將Remote Service聲明與View分離。
ServiceLocator實(shí)現(xiàn)SP。在Cairngorm的demo中,又通過Delegate對象解除Command/Responder和ServiceLocator之間的依賴。這個(gè)Delegate做的事情其實(shí)意義不大,就是調(diào)用ServiceLocator中的Method,設(shè)置莫個(gè)Responder為相應(yīng)遠(yuǎn)程方法的handler。個(gè)人覺得無謂地增加了代碼量,而且Delegate對象也沒實(shí)現(xiàn)SP,也就是說我們每次調(diào)用一次Remote Service中的Method,都要new一個(gè)Delegate對象,實(shí)在浪費(fèi)。
#2.3
ViewLocator/ViewHelper將View(MXML)中夾雜的function與View分離。
ViewHelper有點(diǎn)意思,當(dāng)一個(gè)ViewHelper在某個(gè)MXML頁面中聲明時(shí),如<view:LoginViewHelper id="loginViewHelper" />
#2.4
ModelLocator是一個(gè)marker interface,程序中Model可以放在某個(gè)ModelLocator方便調(diào)用。
#2.5
ValueObject也是一個(gè)marker interface, 基本不需要。
#3
Cairngorm.99給我們開發(fā)Flex程序提供了很不錯(cuò)的架構(gòu)模式,M/V/C/Remote之間可以做到完全解構(gòu)。但在實(shí)際開發(fā)時(shí)沒有必要死扣,代碼結(jié)構(gòu)清晰有活力就好。