H
hjy2000
Unregistered / Unconfirmed
GUEST, unregistred user!
一个高级程序员的困惑！（有内容）
作 者：nettoobad
所属论坛：Delphi
问题点数：20
回复次数：4
发表时间：2001-12-17 0:49:36
2001/07/02 星期一, 是個重要的日子, 這個營業額近一百億的公司, 共計海內外 5 個資料庫
, 11 個營業據點, 12 條 internet 專線, 4700 名員工, 今天要轉換系統, 總公司的 dat
abase 要從 Oracle v7.33 換成 v8.17, 更要從 client/server 換成 3-tier, 經過長時
間的測試再測試, 延後再延後, 今天將不再順延, 全公司就靠妳了, Delphi!
6/30 v7.33 資料庫停止服務, 與其他資料庫中斷 replication, 在資料 export 之後,
當日深夜開始 import 進 v8.17, 這個動作已經演練了好幾次, 一切順利.
7/1 星期日, 外頭是艷陽高照, 假日的辦公大樓, 機房則是幾十台機器發出如火爐般的高
溫, 大家已經在這個小房間裡日以繼夜的熬了好幾個星期, 總算已經到了該攤牌的時候了
, 3 台 ap server 就緒, web-server 啟動成功, 第一個帳戶登入, 第二個帳戶登入, 第
三, 第四...整個過程順利的難以置信, 在向老闆報告了工作狀況後, 確定明天轉換系統!
7/2 星期一, 早晨 8:30 user 開始湧入辦公室, 新的 HomePage show 出以下公告:
1.舊系統所有功能自即日起由新系統替代.
2.在 30 天之內舊系統仍保留查詢功能.
3.海內外之資料同步預定 7 日內恢復.
4.請各位同仁注意所公佈之學習課程.
...
11:00am
[主機還好嗎?]
[沒什麼 loading, 所以還看不出來.]
[為什麼?]
[大部分都還不會操作, 在等訓練課程.]
11:30am
[教室裡有一台 pc 出現 RPC 伺服器的 error message.]
[然後呢?]
[還在解決中.]
11.35am
[不好, 大部分的 user 都出現同樣的訊息, RPC error.]
[程式重新啟動呢?]
[也不行, David 課也教不下去了.]
[server 狀況怎麼樣?]
[Oracle 正常, ap server 沒有 loading, 但也連不上]
[是哪台出問題?]
[好像全掛了.]
...
[通知 user 下課吃飯, 下午繼續!]
大家看了便當, 卻一點食慾都沒有. 離下午上班還有 90 分鐘可以想對策.
[ap 重開就正常, 會不會是剛才線路出問題?]
[可是除了 ap 其他 server 全正常.]
[ap 的網路卡出問題?]
[可是 3 台都掛了.]
[奇怪, 測了這麼久都沒碰到這個什麼 RPC error, 上線第一天就掛了...]
[會不會是這些正式的 server 與之前測試的環境不一樣?]
[唯一不同的就是從前只有一台 ap, 而現在則是 3 台.]
[會不會是 load balancing 出了問題?]
[... 可是, SimpleObject 只是分配一個 ap server 給 client, ap 當掉跟 SimpleObject
有關係嗎?]
[不管, 下午先將 2 台 ap 離線, 只用一台看會不會好一點.]
1:40pm
[各位同仁很抱歉, 因為上午主機出了些問題, 所以現在繼續 ...]
2:00pm
[又是 RPC error!] Jerry 驚叫.
[ap 又掛了.]
[重開!]
[...]
好不容易熬到下班, 也數不清當了幾次. 同樣是這些人, 同樣是愁眉苦臉對著便當吃不下
. 中央空調過了七點就沒了, 而夜卻長的很.
[ok, 看來唯一與測試環境不同的就是 loading, concurrent user 多了, ap 就掛了.]
[今天有多少 user?]
[教室裡 20 個, 外頭也有一些, 但教室這些是跟著老師的課程走, 所以會同時做相同的動
作, 所以 ap 受不了.]
[才 20 個就受不了? 那這什麼爛貨, 還有誰敢用.]
這些人已經幾星期沒睡好覺, David, Jerry 更是好久沒回家了, 心中的怒火似乎就像外頭
的氣溫.
[ap service 是用 Single 或 Multiple?]
[有沒有可能是 Oracle 817 的問題?]
[有沒有可能是 Socket Server 出問題?]
[有沒有可能是 ap 與 Oracle 中間的傳輸有問題?]
...
疑點愈來愈多, 但要從何下手? 而且做任何的改變都等於是拿真實環境做實驗, 一點退路
都沒有, 頭上幾天 user 還能忍受, 只要再過幾天, 肯定就有人告到老闆那兒去, 那就 .
..
[吃飯, 等一下把所有的 ap service 都改成 Single, 而且都裝到 817 同一台, 明天再跑
跑看.]
這個改變可以知道 Single 與 Multiple 有沒有差別, 而且可以把 Oracle 與 ap 中間傳輸的問題給先排除, 讓問
題比較好抓. 唉! 所有的狀況都事先做過測試, 就缺找 20 個人同時 run 一個 program...
7/3 星期二, 大家拖著疲憊的身子, 再度面臨沉重的一天.
[可以上課了嗎?]
[嗯! 開始]
所有人注意的焦點都在 20 個 user 的螢幕.
[RPC, RPC, 不要出來 RPC...]彷彿在唸著咒語.
時間一分一秒的過去.
[有 RPC 嗎?]
[沒有, 可是有 user 的 program run 一半當掉, 死當, 要強迫中斷才能結束.]
[多不多?]
[有幾個!]
[RPC 呢?]
[沒有.]
沒有 RPC error 了, 大家彷彿不信似的. 那到底是因為 Multiple 的問題, 還是 Oracle
與 ap 傳輸的問題造成 RPC?
再改, 下午再把 ap server 回復到 3 台.
中午休息時間似乎對所有的人都是個短暫的解脫, user 可以逃離這個讓人瘋狂的新系統,
而我們也可以關起門來想對策.
[早上 RPC 是沒有了, 可是因為只有一台 ap 而且 Service 都是 Single, 所以排隊的情
形
很嚴重, 往往一個 user 作個查詢要等前面 10 個人 run 出結果, 他才會有回應.]
[這可以先不管, 要確定 RPC 的問題已經解決, 否則這個系統根本 run 不下去.]
下午同樣沒有出現 RPC error, 看來很明顯是因為 Multiple 所造成, 雖然因為加到 3 台 ap server
排隊的現象緩和了些, 但 user 偶而會當掉 program 還是很令人心煩, 不過總比 RPC
要好多了.
[RPC error 是沒了, 可是 user 在抱怨做一個動作要等好久, 也不知道是當了還是在等待.]
[等了多久?]
[有 user 等了一二個小時.]
[天啊! 這麼笨, 當然是當了.]
[可是 user 分不出來要他等多久才算當掉, 而且往往打一張訂單, 在儲存時就沒回應,
你要他放棄將程式中斷, 他會殺了你.]
[...]
又是悶熱的夜晚, 還是這些人, 新系統上線第二天, user 加班變得更晚.
[耶! 存成功了!] 一個 user 冒出了一聲歡呼, 但我們這些人相對不語, 這一點都不好笑,
一筆資料能順利存成功, 變成了上天的恩賜.
這麼龐大的公司, 每天這麼多的交易, 現在竟然建築在一個這麼不穩的系統上, 而我們就
是這些罪魁禍首.
user 也知道要避開白天跟許多人搶 server 的 space, 所以就在晚上補打單子, 但等發現
到也有許多人有共同想法的時候, 也只能互相苦笑捉弄一番.
而我們這些精疲力盡頭腦已經不太清楚的人, 還要等到 user 走光才能開始下一步的實驗.
[ok, 誰能對 program 會死當提出看法?]
[...]
[其實真正死當的並不是這麼多, 因為有些 user 可能在還沒回應前就認為當了而中斷.]
[而且仔細分析並不是每支程式都會當, 而是集中在訂單系統.]
[訂單? 訂單有什麼特別?]
[...]
[訂單 master/detail 關聯比較複雜, 一共有 3 層 8 個 table.]
[...]
[ok, 看樣子要修改程式了.]
等待是令人期待的, 而結果卻是令人失望的, 要對一個正式的環境做實驗或調整, 是一件讓
人手心冒汗的事, 但整件事情的發展已經失去了回頭的機會, 一次一次的失望都是用無數實驗
與時間換來的, 我們已經無法宣告失敗, 要公司的資料庫迴轉到 6/30 的 Oracle 733,
沒有人承受的起這個損失, Oracle 也沒有 support 資料庫的 do
wngrade.
7/4 總公司對其他資料庫的 replication 啟動成功, 雖然新系統仍然有 program 死當的
問題, 但企業的運轉還是不能停的.
7/11 JDN 的 user 連線成功.
7/12 HK 與 MEX 的 user 連線成功.
7/13 SPN 的 user 連線成功.
7/30 新的 HomePage show 出以下公告:
1.舊系統之查詢功能自即日起停止服務.
2.駐外單位已全數連線, 請總公司同仁不要再提供 fax, mail
...
從此總公司 client/server program 與 ASP CGI 網站全數停機, 不分遠近, 所有的 user
都是使用相同的 program 操作, 你可以從 TPE 輸入訂單, 而 MEX 的 user 可以同時在地
球的另一邊將訂單開啟, 3 層 master/detail 共計 8 個 table, 這在過去是不可能實現
的, 照理我們現在應該是歡欣鼓舞開香檳的時候, 但 program 會不定時的當機, 像個陰影
尾隨不掉.
[BDE, Oracle 都做了 tunning, performance 有變好, 可是還是照當, 已經很多人告到老
闆那邊去了.]
[想想一個 user 一天不要多, 只要當二次, 統統加起來就是幾百次, 老闆沒拿刀殺人就很
仁慈了.]
[其實現在很明顯是 Socket server 出問題, 這玩意很不可靠, 但奇怪的是在 Socket ser
ver 掛掉的同時, DCOM 還是可以連的上, 要不要改成用 DCOMConnection 試試看?]
[也好, 死馬當活馬醫.]
8 月中的某一天, 天一樣的熱, 所有的程式都換成了 DCOMConnection.
[user 出現 "interface not support" 的訊息.]
[修改 DCOMCNFG.]
[ok]
替 user 解決 "interface not support" 的訊息不是難事, 重點是我們的運氣似乎開始好
轉.
無疑 DCOM 要比 Socket 穩定許多, 一夜之間 program 變得不會當機了, 但要解決所有 u
ser "interface not support" 的訊息並沒想像中簡單, 尤其是遠端的 WIN95, 98 ME 或 WINNT.
但重要的是可以報告老闆, 我們不會當機了!
解決這個問題不是靠 Borland 的文件, 也不是靠 patch, 而是靠運氣, Borland 並未告
訴妳說 Socket 是有問題, 或是如何去避免, 雖然現在是解決了眼前的問題, 但還有多少
問題是如冰山般未浮現?
以我們這個案例而言, 不靠決策高層堅定的支持, 早就宣告失敗砍人, 有幾個老闆敢拿公
司開玩笑, 做無限制的實驗與等待, 故事的過程中除了對細節有所保留, 但所有的人物與時空背景都屬
真實, 一方面為這場戰役留下紀錄, 也希望給所有投入在 Delphi 的工作者, 事業經營者
做一個參考, 但我必須說既然在官方文件找不到的解答, 就不代表長久有效, 我們現在的
環境是 Windows 2000 + Oracle 817 + Delphi 5.01 + DCOMConnection, 其中有任何一個
改變了, 就可能得從頭開始再玩一遍.
這場仗打完了嗎? 才開始呢! 如果老闆不把我 fire 掉, 最起碼現在還有許多問題要克服:
1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火
牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點
不知該由 Microsoft 或 Borland 出面解決?
2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且
不可預期.
3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland
的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connectio
n 結束而釋放, 在 user 數多時這是很嚇人的.
6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所
適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
簡單的講, 在有防火牆的 internet 環境裡目前 Delphi 似乎提不出解決的方法, 相信很
多人會建議採用 web solution, snap, soap, web service...但我這裡講的是 ap, 若說
要靠 web 做一套複雜的 MRP or ERP? 唉! 那只能祝你好運了!
放棄 Delphi? 坦白說不是沒有這個念頭, 但你會建議用什麼來替代? IBM 會說用 Webspher
e, Oracle 會說用 application server 9i, 每個公司都可以派一個 team 的 sales 來拜
訪你, 但沒有一家會準備一個李維來解決你的問題, 若說要離開熟悉的 Delphi 投入另一批
sales 的甜言蜜語, 看來只是找機會讓老闆炒你魷魚.
終於還是鼓起勇氣將手上的 Delphi 6, Oracle 9i Database, Oracle Application Server
9i 分別裝進 3 台 server, 這一次要測的項目可多了:
1.Oracle 817 資料可否 export 到 9i?
2.Delphi 6 的 CORBA 與 Oracle 所附的 Visibroker 可否並存?
3.CORBA client 可否穿透 internet 連結 CORBA server.
4.CORBA 的 load balancing.
5.CORBA 的承受能力?
6.Delphi 6 的 Socket 可有改善?
只是為了實驗 817 database export 到 9i, 就將 Oracle 9i 重裝了好多次, 因為根本
無法成功, 這點 Oracle 也提不出解決方法.
為了要將 Oracle Application Server 9i 連結到資料庫, 也重灌了 n 次才確定, 9i A
pplication Server 竟然不能連結 9i Database, 只能連 8.1.x, 這可真夠邪門的了.
所謂重灌是指連 Windows server 都重新安裝, 你能想像花了多少冤枉時間去 try 一些令
人無法置信的結果, 真正好戲是等到測 Delphi 6 的 CORBA 才開始登場.
當 Oracle 9i database, 9i Application Server 與 Delphi 6 都裝完以後, 你會發
現竟然並存了好幾個 Visibroker 的版本, 光 Delphi 6 就可以讓你選擇 4.x 與 3.x
二種,
開玩笑, 當然是裝新版 4.x, 哪有裝舊的.
結果 Delphi 6 的資料庫元件竟然無法連結 CORBA 4.x, 唉! 只好又移除 Delphi 6,
再重裝一次, 這次就安裝了 CORBA 3.x, 果然, 可以順利做些實驗, client 可以連上 COR
BA server, 而且 load balancing 也生效, 如同李維書上所說, 使用 CORBA connectio
n 可以不用仰賴 SimpleObject 做 load balancing, 程式簡單多了, 但仍然無法穿透 in
ternet.
再來的實驗呢? 做不下去了, 無數次的安裝移除, Delphi 6 不再讓我註冊了, Borland
美國的註冊 server 從此不再接受我的註冊, 縱然你手上握的是原版光碟, 但一下子卻
成了非法的使用者, 我睜大了眼睛實在不敢相信, 這...Borland 實在讓我灰心透了,
不談這個小動作合不合理, 我實在對這一行突生厭惡, 我相信所有投入這個工作的人起始
的出發點都是可敬可佩的, 我沒有遇到一個 programmer 是為了賺好多錢, 會在年輕時就
開始了日以繼夜的工作, 他們所擁有的只是一個夢想, 雖不能當大老闆統領千軍萬馬, 但
也能藉著完成一個電腦系統而實現管理化的那份成就感, 其中有多少人因為開發工具的先
天不良而宣告失敗, 輕則離職, 重則賠錢挨告, 而所有開發工具的廠商能提出解決的方案
卻是少之又少, 若你用 VB or Delphi 接一個 project, 最後可能因為失敗而被告, 但卻
從來就沒有一個開發工具廠商因為這種事而被告, 他們每年不斷的要你花錢買一個修補漏
洞的新版, 另外再送一些不穩定的新功能讓你測試, 現在, 乾脆直接說:
[嘿! 這個功能你只能測 10 次, 之後就 game over, 你必須重買一套.]
乖乖! 一套 Delphi 6 client/server 你知道要多少錢? 這個解決的方法歷經二個月 Bor
land 還是沒給我答覆, 也好, 不作實驗時間倒多出來了, 除了賞楓賞
雪還可以寫寫文章投稿, 只是若不能再成為 Delphi 的 "合法" user, 這大概也是我在李
維論壇的最後一篇, 從此不再玩 Delphi 了!
--
james
回复贴子：
回复人： karma(无为) (2001-12-17 4:35:14) 得0分
very interesting
回复人： chuixue(吹雪) (2001-12-17 8:39:38) 得0分
不错不错!!!
回复人： goalitaly(迈克尔.朱珠) (2001-12-17 8:45:02) 得0分
hehe !!
回复人： Bellamy(酷公爵) (2001-12-17 9:03:31) 得0分
he he !
bu hui ba !
作 者：nettoobad
所属论坛：Delphi
问题点数：20
回复次数：4
发表时间：2001-12-17 0:49:36
2001/07/02 星期一, 是個重要的日子, 這個營業額近一百億的公司, 共計海內外 5 個資料庫
, 11 個營業據點, 12 條 internet 專線, 4700 名員工, 今天要轉換系統, 總公司的 dat
abase 要從 Oracle v7.33 換成 v8.17, 更要從 client/server 換成 3-tier, 經過長時
間的測試再測試, 延後再延後, 今天將不再順延, 全公司就靠妳了, Delphi!
6/30 v7.33 資料庫停止服務, 與其他資料庫中斷 replication, 在資料 export 之後,
當日深夜開始 import 進 v8.17, 這個動作已經演練了好幾次, 一切順利.
7/1 星期日, 外頭是艷陽高照, 假日的辦公大樓, 機房則是幾十台機器發出如火爐般的高
溫, 大家已經在這個小房間裡日以繼夜的熬了好幾個星期, 總算已經到了該攤牌的時候了
, 3 台 ap server 就緒, web-server 啟動成功, 第一個帳戶登入, 第二個帳戶登入, 第
三, 第四...整個過程順利的難以置信, 在向老闆報告了工作狀況後, 確定明天轉換系統!
7/2 星期一, 早晨 8:30 user 開始湧入辦公室, 新的 HomePage show 出以下公告:
1.舊系統所有功能自即日起由新系統替代.
2.在 30 天之內舊系統仍保留查詢功能.
3.海內外之資料同步預定 7 日內恢復.
4.請各位同仁注意所公佈之學習課程.
...
11:00am
[主機還好嗎?]
[沒什麼 loading, 所以還看不出來.]
[為什麼?]
[大部分都還不會操作, 在等訓練課程.]
11:30am
[教室裡有一台 pc 出現 RPC 伺服器的 error message.]
[然後呢?]
[還在解決中.]
11.35am
[不好, 大部分的 user 都出現同樣的訊息, RPC error.]
[程式重新啟動呢?]
[也不行, David 課也教不下去了.]
[server 狀況怎麼樣?]
[Oracle 正常, ap server 沒有 loading, 但也連不上]
[是哪台出問題?]
[好像全掛了.]
...
[通知 user 下課吃飯, 下午繼續!]
大家看了便當, 卻一點食慾都沒有. 離下午上班還有 90 分鐘可以想對策.
[ap 重開就正常, 會不會是剛才線路出問題?]
[可是除了 ap 其他 server 全正常.]
[ap 的網路卡出問題?]
[可是 3 台都掛了.]
[奇怪, 測了這麼久都沒碰到這個什麼 RPC error, 上線第一天就掛了...]
[會不會是這些正式的 server 與之前測試的環境不一樣?]
[唯一不同的就是從前只有一台 ap, 而現在則是 3 台.]
[會不會是 load balancing 出了問題?]
[... 可是, SimpleObject 只是分配一個 ap server 給 client, ap 當掉跟 SimpleObject
有關係嗎?]
[不管, 下午先將 2 台 ap 離線, 只用一台看會不會好一點.]
1:40pm
[各位同仁很抱歉, 因為上午主機出了些問題, 所以現在繼續 ...]
2:00pm
[又是 RPC error!] Jerry 驚叫.
[ap 又掛了.]
[重開!]
[...]
好不容易熬到下班, 也數不清當了幾次. 同樣是這些人, 同樣是愁眉苦臉對著便當吃不下
. 中央空調過了七點就沒了, 而夜卻長的很.
[ok, 看來唯一與測試環境不同的就是 loading, concurrent user 多了, ap 就掛了.]
[今天有多少 user?]
[教室裡 20 個, 外頭也有一些, 但教室這些是跟著老師的課程走, 所以會同時做相同的動
作, 所以 ap 受不了.]
[才 20 個就受不了? 那這什麼爛貨, 還有誰敢用.]
這些人已經幾星期沒睡好覺, David, Jerry 更是好久沒回家了, 心中的怒火似乎就像外頭
的氣溫.
[ap service 是用 Single 或 Multiple?]
[有沒有可能是 Oracle 817 的問題?]
[有沒有可能是 Socket Server 出問題?]
[有沒有可能是 ap 與 Oracle 中間的傳輸有問題?]
...
疑點愈來愈多, 但要從何下手? 而且做任何的改變都等於是拿真實環境做實驗, 一點退路
都沒有, 頭上幾天 user 還能忍受, 只要再過幾天, 肯定就有人告到老闆那兒去, 那就 .
..
[吃飯, 等一下把所有的 ap service 都改成 Single, 而且都裝到 817 同一台, 明天再跑
跑看.]
這個改變可以知道 Single 與 Multiple 有沒有差別, 而且可以把 Oracle 與 ap 中間傳輸的問題給先排除, 讓問
題比較好抓. 唉! 所有的狀況都事先做過測試, 就缺找 20 個人同時 run 一個 program...
7/3 星期二, 大家拖著疲憊的身子, 再度面臨沉重的一天.
[可以上課了嗎?]
[嗯! 開始]
所有人注意的焦點都在 20 個 user 的螢幕.
[RPC, RPC, 不要出來 RPC...]彷彿在唸著咒語.
時間一分一秒的過去.
[有 RPC 嗎?]
[沒有, 可是有 user 的 program run 一半當掉, 死當, 要強迫中斷才能結束.]
[多不多?]
[有幾個!]
[RPC 呢?]
[沒有.]
沒有 RPC error 了, 大家彷彿不信似的. 那到底是因為 Multiple 的問題, 還是 Oracle
與 ap 傳輸的問題造成 RPC?
再改, 下午再把 ap server 回復到 3 台.
中午休息時間似乎對所有的人都是個短暫的解脫, user 可以逃離這個讓人瘋狂的新系統,
而我們也可以關起門來想對策.
[早上 RPC 是沒有了, 可是因為只有一台 ap 而且 Service 都是 Single, 所以排隊的情
形
很嚴重, 往往一個 user 作個查詢要等前面 10 個人 run 出結果, 他才會有回應.]
[這可以先不管, 要確定 RPC 的問題已經解決, 否則這個系統根本 run 不下去.]
下午同樣沒有出現 RPC error, 看來很明顯是因為 Multiple 所造成, 雖然因為加到 3 台 ap server
排隊的現象緩和了些, 但 user 偶而會當掉 program 還是很令人心煩, 不過總比 RPC
要好多了.
[RPC error 是沒了, 可是 user 在抱怨做一個動作要等好久, 也不知道是當了還是在等待.]
[等了多久?]
[有 user 等了一二個小時.]
[天啊! 這麼笨, 當然是當了.]
[可是 user 分不出來要他等多久才算當掉, 而且往往打一張訂單, 在儲存時就沒回應,
你要他放棄將程式中斷, 他會殺了你.]
[...]
又是悶熱的夜晚, 還是這些人, 新系統上線第二天, user 加班變得更晚.
[耶! 存成功了!] 一個 user 冒出了一聲歡呼, 但我們這些人相對不語, 這一點都不好笑,
一筆資料能順利存成功, 變成了上天的恩賜.
這麼龐大的公司, 每天這麼多的交易, 現在竟然建築在一個這麼不穩的系統上, 而我們就
是這些罪魁禍首.
user 也知道要避開白天跟許多人搶 server 的 space, 所以就在晚上補打單子, 但等發現
到也有許多人有共同想法的時候, 也只能互相苦笑捉弄一番.
而我們這些精疲力盡頭腦已經不太清楚的人, 還要等到 user 走光才能開始下一步的實驗.
[ok, 誰能對 program 會死當提出看法?]
[...]
[其實真正死當的並不是這麼多, 因為有些 user 可能在還沒回應前就認為當了而中斷.]
[而且仔細分析並不是每支程式都會當, 而是集中在訂單系統.]
[訂單? 訂單有什麼特別?]
[...]
[訂單 master/detail 關聯比較複雜, 一共有 3 層 8 個 table.]
[...]
[ok, 看樣子要修改程式了.]
等待是令人期待的, 而結果卻是令人失望的, 要對一個正式的環境做實驗或調整, 是一件讓
人手心冒汗的事, 但整件事情的發展已經失去了回頭的機會, 一次一次的失望都是用無數實驗
與時間換來的, 我們已經無法宣告失敗, 要公司的資料庫迴轉到 6/30 的 Oracle 733,
沒有人承受的起這個損失, Oracle 也沒有 support 資料庫的 do
wngrade.
7/4 總公司對其他資料庫的 replication 啟動成功, 雖然新系統仍然有 program 死當的
問題, 但企業的運轉還是不能停的.
7/11 JDN 的 user 連線成功.
7/12 HK 與 MEX 的 user 連線成功.
7/13 SPN 的 user 連線成功.
7/30 新的 HomePage show 出以下公告:
1.舊系統之查詢功能自即日起停止服務.
2.駐外單位已全數連線, 請總公司同仁不要再提供 fax, mail
...
從此總公司 client/server program 與 ASP CGI 網站全數停機, 不分遠近, 所有的 user
都是使用相同的 program 操作, 你可以從 TPE 輸入訂單, 而 MEX 的 user 可以同時在地
球的另一邊將訂單開啟, 3 層 master/detail 共計 8 個 table, 這在過去是不可能實現
的, 照理我們現在應該是歡欣鼓舞開香檳的時候, 但 program 會不定時的當機, 像個陰影
尾隨不掉.
[BDE, Oracle 都做了 tunning, performance 有變好, 可是還是照當, 已經很多人告到老
闆那邊去了.]
[想想一個 user 一天不要多, 只要當二次, 統統加起來就是幾百次, 老闆沒拿刀殺人就很
仁慈了.]
[其實現在很明顯是 Socket server 出問題, 這玩意很不可靠, 但奇怪的是在 Socket ser
ver 掛掉的同時, DCOM 還是可以連的上, 要不要改成用 DCOMConnection 試試看?]
[也好, 死馬當活馬醫.]
8 月中的某一天, 天一樣的熱, 所有的程式都換成了 DCOMConnection.
[user 出現 "interface not support" 的訊息.]
[修改 DCOMCNFG.]
[ok]
替 user 解決 "interface not support" 的訊息不是難事, 重點是我們的運氣似乎開始好
轉.
無疑 DCOM 要比 Socket 穩定許多, 一夜之間 program 變得不會當機了, 但要解決所有 u
ser "interface not support" 的訊息並沒想像中簡單, 尤其是遠端的 WIN95, 98 ME 或 WINNT.
但重要的是可以報告老闆, 我們不會當機了!
解決這個問題不是靠 Borland 的文件, 也不是靠 patch, 而是靠運氣, Borland 並未告
訴妳說 Socket 是有問題, 或是如何去避免, 雖然現在是解決了眼前的問題, 但還有多少
問題是如冰山般未浮現?
以我們這個案例而言, 不靠決策高層堅定的支持, 早就宣告失敗砍人, 有幾個老闆敢拿公
司開玩笑, 做無限制的實驗與等待, 故事的過程中除了對細節有所保留, 但所有的人物與時空背景都屬
真實, 一方面為這場戰役留下紀錄, 也希望給所有投入在 Delphi 的工作者, 事業經營者
做一個參考, 但我必須說既然在官方文件找不到的解答, 就不代表長久有效, 我們現在的
環境是 Windows 2000 + Oracle 817 + Delphi 5.01 + DCOMConnection, 其中有任何一個
改變了, 就可能得從頭開始再玩一遍.
這場仗打完了嗎? 才開始呢! 如果老闆不把我 fire 掉, 最起碼現在還有許多問題要克服:
1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火
牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點
不知該由 Microsoft 或 Borland 出面解決?
2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且
不可預期.
3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland
的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connectio
n 結束而釋放, 在 user 數多時這是很嚇人的.
6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所
適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
簡單的講, 在有防火牆的 internet 環境裡目前 Delphi 似乎提不出解決的方法, 相信很
多人會建議採用 web solution, snap, soap, web service...但我這裡講的是 ap, 若說
要靠 web 做一套複雜的 MRP or ERP? 唉! 那只能祝你好運了!
放棄 Delphi? 坦白說不是沒有這個念頭, 但你會建議用什麼來替代? IBM 會說用 Webspher
e, Oracle 會說用 application server 9i, 每個公司都可以派一個 team 的 sales 來拜
訪你, 但沒有一家會準備一個李維來解決你的問題, 若說要離開熟悉的 Delphi 投入另一批
sales 的甜言蜜語, 看來只是找機會讓老闆炒你魷魚.
終於還是鼓起勇氣將手上的 Delphi 6, Oracle 9i Database, Oracle Application Server
9i 分別裝進 3 台 server, 這一次要測的項目可多了:
1.Oracle 817 資料可否 export 到 9i?
2.Delphi 6 的 CORBA 與 Oracle 所附的 Visibroker 可否並存?
3.CORBA client 可否穿透 internet 連結 CORBA server.
4.CORBA 的 load balancing.
5.CORBA 的承受能力?
6.Delphi 6 的 Socket 可有改善?
只是為了實驗 817 database export 到 9i, 就將 Oracle 9i 重裝了好多次, 因為根本
無法成功, 這點 Oracle 也提不出解決方法.
為了要將 Oracle Application Server 9i 連結到資料庫, 也重灌了 n 次才確定, 9i A
pplication Server 竟然不能連結 9i Database, 只能連 8.1.x, 這可真夠邪門的了.
所謂重灌是指連 Windows server 都重新安裝, 你能想像花了多少冤枉時間去 try 一些令
人無法置信的結果, 真正好戲是等到測 Delphi 6 的 CORBA 才開始登場.
當 Oracle 9i database, 9i Application Server 與 Delphi 6 都裝完以後, 你會發
現竟然並存了好幾個 Visibroker 的版本, 光 Delphi 6 就可以讓你選擇 4.x 與 3.x
二種,
開玩笑, 當然是裝新版 4.x, 哪有裝舊的.
結果 Delphi 6 的資料庫元件竟然無法連結 CORBA 4.x, 唉! 只好又移除 Delphi 6,
再重裝一次, 這次就安裝了 CORBA 3.x, 果然, 可以順利做些實驗, client 可以連上 COR
BA server, 而且 load balancing 也生效, 如同李維書上所說, 使用 CORBA connectio
n 可以不用仰賴 SimpleObject 做 load balancing, 程式簡單多了, 但仍然無法穿透 in
ternet.
再來的實驗呢? 做不下去了, 無數次的安裝移除, Delphi 6 不再讓我註冊了, Borland
美國的註冊 server 從此不再接受我的註冊, 縱然你手上握的是原版光碟, 但一下子卻
成了非法的使用者, 我睜大了眼睛實在不敢相信, 這...Borland 實在讓我灰心透了,
不談這個小動作合不合理, 我實在對這一行突生厭惡, 我相信所有投入這個工作的人起始
的出發點都是可敬可佩的, 我沒有遇到一個 programmer 是為了賺好多錢, 會在年輕時就
開始了日以繼夜的工作, 他們所擁有的只是一個夢想, 雖不能當大老闆統領千軍萬馬, 但
也能藉著完成一個電腦系統而實現管理化的那份成就感, 其中有多少人因為開發工具的先
天不良而宣告失敗, 輕則離職, 重則賠錢挨告, 而所有開發工具的廠商能提出解決的方案
卻是少之又少, 若你用 VB or Delphi 接一個 project, 最後可能因為失敗而被告, 但卻
從來就沒有一個開發工具廠商因為這種事而被告, 他們每年不斷的要你花錢買一個修補漏
洞的新版, 另外再送一些不穩定的新功能讓你測試, 現在, 乾脆直接說:
[嘿! 這個功能你只能測 10 次, 之後就 game over, 你必須重買一套.]
乖乖! 一套 Delphi 6 client/server 你知道要多少錢? 這個解決的方法歷經二個月 Bor
land 還是沒給我答覆, 也好, 不作實驗時間倒多出來了, 除了賞楓賞
雪還可以寫寫文章投稿, 只是若不能再成為 Delphi 的 "合法" user, 這大概也是我在李
維論壇的最後一篇, 從此不再玩 Delphi 了!
--
james
回复贴子：
回复人： karma(无为) (2001-12-17 4:35:14) 得0分
very interesting
回复人： chuixue(吹雪) (2001-12-17 8:39:38) 得0分
不错不错!!!
回复人： goalitaly(迈克尔.朱珠) (2001-12-17 8:45:02) 得0分
hehe !!
回复人： Bellamy(酷公爵) (2001-12-17 9:03:31) 得0分
he he !
bu hui ba !