《玫瑰的名字》閱讀筆記 4

7/05/2009

讀完了,整理一下看完之後的感想。

作者以主角埃森的手稿來呈現發生於中古世紀一宗謀殺案的來龍去脈。當時埃森還是一名非常年輕的見習僧,跟著學識淵博、思緒縝密的老師威廉一起拜訪一家修道院,而手稿的內容,便是他們從到達修道院的那天起,一連七天內發生的事情。整部小說的結構也是以這七天的時間軸來安排。

他們到達修道院的第一天,便發生一起疑似謀殺案件,由此揭開懸疑的序幕,吸引讀者跟著這對師徒抽絲剝繭,找出兇案的真相。這七天當中的每一天都有新的血案和新的線索,中間伴隨一些宗教歷史的陳述、神學與哲學的辯論、各種情慾的掙扎--男女、男男都有,其中有一小段全書唯一的短暫愛情(以現代人的話來講,其實就是一夜情啦),卻是悲劇。對中古世紀歐洲各教派之間的鬥爭歷史不熟的人(像我就是,全然陌生),讀起來可能會有點吃力,尤其有些地方還得對照英文版來看,不然很難看懂;其中有些我覺得是中文翻譯的問題,這在前幾篇的筆記已經有稍微寫一點,這裡就不再談了。其實跳過這些比較嚴肅、花腦筋的部分,純粹把它當作偵探小說來讀也 OK,只不過略嫌可惜,而且到最後結局時,對主角所下的神學結論可能就不會有太大的感覺。

這裡摘錄小說結尾時,威廉與埃森的對話(p. 444):

威廉:「......要接受世界上不可能有秩序存在的概念是很難的,因為那違反了上帝的自由意志及全能的力量。因此上帝的自由就是我們罪惡的宣告,至少是我們驕傲的宣告。」(後面這句翻譯也怪怪的,原文是: So the freedom of God is our condemnation, or at least the condemnation of our pride)

我(埃森)--畢生第一次也是最後一次的--貿然提出了一項神學的結論:「可是一個『必然』存在的人怎麼會全然被『可能』所污染?那麼,上帝和原始的混沌有何差別呢?確定上帝絕對的全能和絕對的自由,並不是等於顯示上帝並不存在嗎?」

威廉面無表情地望著我,說道:「如果一個學者對你的問題回答是的話,他怎麼繼續傳達他的學識呢?」

還有我最喜歡的一句:

說不定,那些深愛人類的人所負的任務,是使人們嘲笑真理,使真理變得可笑;唯一的真理,在於學習讓我們自己從對真理的瘋狂熱情中解脫。 (p.442)
....the only truth lies in learning to free ourselves from insane passion for the truth.

總結

以個人粗淺的體會和笨拙的詞彙,若要對這本小說下個總結,應該會是:「在福爾摩斯式的解謎過程中巧妙融入神學與哲學的思辯; 饒富趣味與知性,結局引人深思。

這些只是個人的一點筆記而已,博客來網站上有一篇署名「銀河戲」的讀者評論,寫得專業多了,我覺得甚至比中文版的導讀還好(但稍微有雷)。有興趣的人不妨先看看那篇書評再閱讀本書,應該更能掌握書中要旨,體會更多樂趣。

《玫瑰的名字》閱讀筆記 3

7/04/2009
上一篇筆記一樣,這篇也是記錄我讀《玫瑰的名字》時碰到的怪句。
有時候,書上的每個字都認得,兜在一起卻完全看不懂。在《玫瑰的名字》裡面就有這麼一段,反覆看幾遍還是不懂:

《玫瑰的名字》閱讀筆記 2

7/03/2009
都說不雞蛋裡挑骨頭了,還是忍不住..... >_<|||

《玫瑰的名字》閱讀筆記 1

7/02/2009

書名:玫瑰的名字
作者:Umberto Eco/著
譯者:謝瑤玲
出版社:皇冠
出版日期:1993年09月15日


這本小說的中文版已經出版超過 15 年了。在網路上看到推薦文,便將屢屢啃食不下的《罪與罰》先晾在一邊,改看這本。

SQL Server Connection Forcibly Closed

7/02/2009
又一個有點麻煩的問題:在 server farm 環境下,利用 SQL Server 資料庫來儲存 ASP.NET 網站的 sessions,可就是有某一台 app server 會三不五時(每週一兩次或者完全沒有)出現無法連接 SQL Server 的錯誤訊息:
TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host

當此問題發生時,我的伺服器當機偵測程式會發送 MSN 通知和 e-mail 給我。麻煩的地方在於,如果在收到通知訊息時立刻用瀏覽器開啟出問題的 app server 的網頁,卻又發現是正常的。也就是說,這個問題既不定時出現,出現的時間也很短暫,很難將它「鎖定」。

在 MSDN 論壇上找到一帖相關討論:
http://social.msdn.microsoft.com/forums/en-US/sqlnetfx/thread/4895d56b-716f-4f82-860f-0aa161d327cc/

看來還挺多人碰到這種怪問題,但是對發生的原因仍莫衷一是,建議的解法也五花八門。大略爬完這一長串討論之後,打算嘗試兩種解法。

解法 (1):修改 SQL Server 的遠端登入逾時時間

如下圖所示:



此解法似乎有點駝鳥心態:反正可能是某種神祕未知的網路傳輸或連線資源管理問題所致,而且出現的時間很短暫,過幾十秒就恢復了,那就乾脆延長逾時時間,把這些可能發生的短暫延遲給壓下去。

解法 (2):關閉 Connection Pooling

這是我最不希望的做法(因為會影響效能),但不得已時也只能試試看了。

結果

先採用解法 (1) 之後,經過一個月了,一直都沒有再發生同樣的問題。

那就樂得當個鴕鳥吧 :)

後記:結果後來終於找到真正原因,說出來還真的很不好意思....原來,SQL Server Agent 的排程出了問題,無法正常執行定期刪除 ASP.NET session 的工作,以至於 session 資料表持續累積、長大,大到令我難以想像的地步,因而影響了 SQL Server 的運行。
技術提供:Blogger.