Using critical sections

話說BCB在執行緒中有同步的指令，但這是應用在VCL元件上面，在不用到VCL的埸合時，我們就可以利用「Critical Sections」來對多執行緒做排序處理，以下是從BCB的help中節錄出來的：

If objects do not provide built-in locking, you can use a critical section. Critical sections work like gates that allow only a single thread to enter at a time. To use a critical section, create a global instance of TCriticalSection. TCriticalSection has two methods, Acquire (which blocks other threads from executing the section) and Release (which removes the block).

Each critical section is associated with the global memory you want to protect. Every thread that accesses that global memory should first use the Acquire method to ensure that no other thread is using it. When finished, threads call the Release method so that other threads can access the global memory by calling Acquire.

Warning: Critical sections only work if every thread uses them to access the associated global memory. Threads that ignore the critical section and access the global memory without calling Acquire can introduce problems of simultaneous access.

For example, consider an application that has a global critical section variable, pLockXY, that blocks access to global variables X and Y. Any thread that uses X or Y must surround that use with calls to the critical section such as the following:

pLockXY->Acquire(); // lock out other threads
try
{
  Y = sin(X);
}
__finally
{
  pLockXY->Release();
}

將存很久的草稿拿出來潤一下

哈哈
看起來一星期沒更新了，事實上是存成草稿了

上星期還發生了斷後照鏡事件
以及深坑、石碇之旅
有時間再來回顧一下唄~~呵呵

太慢太慢!太慢了啦!

話說前一陣子買了一顆900的前輪,心裡毛毛的
今天早上因為下雨,實在的怕死的小寶騎得非常慢

慢到小公主都趕不上火車了，因為原本10分鐘的車程，騎了20分鐘

「真慢！會不會太誇張了！」
小公主生氣了。

在沒有趕上火車的小公主氣憤難耐，打電話來「客訴」

可真是任性的小公主啊

「我可是因為擔心摔車才會騎這麼慢的咧。」我說
「那你為何就不能跟別人騎的一樣呢，別人就不是買比你還便宜的買菜胎嗎！」
「……」

真是一千萬個無言啊……

GPS...真難決擇…

最近看到家樂福在出清 Garmin nuvi 200 (NT 2990)
想說去買一台，這樣搭配景點書，就能開心地帶著小公主四處趴趴走

想不到逛了兩家，都只剩展示機，而且還…
1. 少配件(無傳輸線及充電器)
2. 外觀嚴重刮傷

…這樣叫我怎麼買得下去

手邊還有台ipaq…1930 古早機，如果買了gps，這樣家裡又多了一台展示機，一整個很敗家…

還是買顆SDIO的GPS吧，這樣我的PDA就有生存下去的空間了

一顆要價6張小朋友……

我我我……還是再繼續觀望吧……

Firebird 不支援 TRUNCATE TABLE 指令

來源：http://www.firebirdnews.org/?p=2075=1
以下節錄：

Few notes about level of support of TRUNCATE statement in Firebird :

a) as we have no IDENTITY we can ignore and all related rules
(Syntax rule 4, Genereal rule

Firebird中沒有IDENTITY，所以不用找了 (笑)

b) Syntax rule 2 means TRUNCATE TABLE is not applicable to VIEW’s

TRUNCATE TABLE 不能用在VIEW's

c) Syntax rule 3 means truncated table must not participate in FOREIGN KEY constraints as
master table.
ORACLE relaxed this rule and allow self-referenced constraints. I think we can follow it.

d) as we have no subrows we can ignore General rule 5

e) it will be good to implement TRUNCATE privilege to satisfy Access rules but for the first time
we can allow to TRUNCATE table only for SYSDBA and OWNER.

Firebird資料庫有優異的TRUNCATE存取規則，但初步我們只開放「SYSDBA」和「OWNER」有TRUNCATE權限。

ORACLE used DROP TABLE privilege to control usage of TRUNCATE TABLE statement, while MSSQL used ALTER TABLE privilege.

From the implementation point of view i have some concerns. All the code which released
table’s and indexes pages without removing relation itself is already present. It may require
some small changes but i see no problem with it.

The main concern is about rollback’s (or undo). If we will perform TRUNCATE TABLE as usual
DML statement, i.e. not defer it to transaction commit time, then we must implement support
for undo-log. Also we must decide if we will preserve truncated contents for older still active
concurrent transactions. And specify when this content will be erased finally.

Another approach is to require exclusive lock on table when TRUNCATE is issued (to prevent
any concurrent access to table’s data) and to defer TRUNCATE execution to the commit time. It
allows us to not preserve table contents for the indefinite time and to avoid complex manipulations with undo-log.

Note, ORACLE can’t rollback TRUNCATE statement. MSSQL 2005 don’t log truncation of big
objects and defer physical deallocation until commit time. All pages remains locked until commit
so no concurrent access to truncated data is allowed, AFAIU. IIRC, MSSQL before 2005 also can’t
rollback TRUNCATE statement.

看來是為了安全性的考量…

(20090429修改--始)

Firebird說明仍能有條件地使用 TRUNCATE 指令

但我怎麼樣都試不出來……

(20090429修改--完)

要刪資料？只能慢慢刪或重建table了…Orz

當 C++ Builder 遇上 Firebird

最近將自己專案裡所連結的Database由 BDE的 Parabox變更為 Firebird，而連結方式也由萬年不化的 BDE，改成由當時 Borland主推的 dbExpress來連結。

當初在做設計變更時，針對這個程式，我想要：
1. 切換到 MySQL、MS SQL、Oracle等之類的SQL資料庫能夠短時間修改完成
2. 封裝時能夠更簡潔
3. 嚐試更新的資料庫程式設計
4. 未來在變為 Multi-Tier架構時較能無痛升級

事實上，就是一個字 --「爽」！

反正…對dbExpress就是很嚮往，我就是要改就對了。

話說，Paradox是屬於「單機檔案型資料庫」而 Firebird是屬於「SQL型資料庫」，也就是說，必須裝個服務(SERVICE)才能夠使用。
這可怎麼辦才好呢？

這時突然看到「Embedded」--將SQL指令封裝在一個 dll檔案中，做為DB與程式間的橋樑，在單機的環境中就不須安裝服務了。

「做得非常好呀！」

Embedded中有三個產品 -- SQLite、Berkeley DB、Firebird embedded 三個。

Berkeley DB就不用看了，為了提高效能而完完全全的使用API來處理。
(等我開新專案時再來考慮)

SQLite 則有Borland的三方 DBX Driver，但使用上 bug一堆 (最明顯的是Refresh後資料庫連線會斷開，而且必須重開應用程式才能連上)，連自帶的demo也開不了內附的db……什麼鬼！

最後就是 Firebird Embedded，其實主要的好處就是與 Interbase相通，ib的 dbx driver可以直上 Firebird，很方便！

於是乎，就開始將程式修改連結方式，一直到…

「咦！2.1.0出了耶，趕快來更新！」

不更新還好，一更新…

「哇哇哇！我table的合併顯示出不來了！」

在 DBX上的操作開始出狀況了，於是…又改回為1.5.5.......

1.5.5很好嗎？
只要 「fbembed.dll」、「ib_util.dll」這兩個檔案就可以啟動，有沒有很好？當然好！
但在壓力測試時，在總筆數達4萬筆後…

450mb突破！

什麼鬼！最好是能暴增到這麼多啦！
而且效能變得更差！ 在這之後，每 insert into 1筆資料，需要

5~10秒！

真是驚死人的數據！而且無解……
怎麼辦…程式改完才出現這樣的情況…

而且，這不是C++ Builder的問題哦，因為在FB專用的gui管理工具所呈現的，也是一樣出乎意料的慢，所以這應該是 FB 1.5.5的問題。

在不得已的情況下，只好再試試看 FB最新的 2.1.1版了。
將450MB的DB匯出 SQL檔，然後再輸入到新的FB2.1.1 DB中(這個工作就花了8個小時...)

多少？

3 MB

…一整個無言，而且效能上依舊犀利

那就繼續用 BCB6 + FB 吧……

好痛…看來我不適合做家事…

前幾天在家裡閒著沒事，想說來打掃一下家裡吧！

於是就拿了新買的吸塵器來整理家裡地板

還沒開始整理，才準備要抽吸塵器的電源線，正在蹲下時…

【趴噠】

「好痛！」

我口愛滴小pp被桌角刮了一個大洞，皮掉了一塊

痛到爆！！！

已經過了好幾天，現在坐下時…居然還會痛…(泣)

我想，或許我是天生的富貴命吧~~~~~~哈哈！