灵魂的骨头 ...灵魂的骨头... http://finalbone.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 管窥周易（003） finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/210690  发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

自强不息 象曰：天行健，君子以自强不息。

 

厚德载物 象曰：地势坤，君子以厚德载物。

 

之所以对周易感兴趣，是因为发现周易是浸透在中国人骨子里的东西，不管本人有没有觉察，没有人可以脱离这种影响，就像上面两个耳熟能详的成语一样，它早已深入了国人生活的方方面面...

 

曾国藩曾经说过，三天不读周易就不像人了，就不知道怎样活人了。也许我们不用达到曾国藩的地步，但是对于影响中国乃至世界几千年的学说，了解一下总没有坏处...

 

今天有时间就多写一点... 一个事物想引起大家的注意与兴趣总得有些独特的魅力，那么周易的魅力在哪里呢？

 

有人说周易揭示了万事万物的演变规律，而且屡试不爽！这多牛X啊～ 还有就是周易的预测与占卜用途，试想一下可以预测彩票与股指是多么幸福的一件事，呵呵～

 

事实证明周易没有那么神，但也不是一无是处，这本身也是矛盾的对立统一吧～ 通过实践，人们发现周易的预测占卜有时候惊人的准确，有时候离题万里，保守的人会抓住周易的模糊与不精确性直接将其打入地狱，迷信的或者另有企图的人会使尽全身解数神话它...

 

面对这种复杂问题，西方人发明了辩证法，而我们有周易，骨子里这是同样的东西，说了一圈又回来了，再次证明周易可以揭示万事万物的基本规律...

 

对于周易的预测原理，我发现很多人都对此感兴趣，而且进行了深入的研究，但是大都在研究的过程中迷失或者停滞不前，也许是目前人类的智慧与科技水平不足以解开这个迷吧～也正是因为这种局限性，各种伪科学盛行，有分辨能力的人是不屑于这些草根理论的...

 

其实研究周易的更大一部分人是迷失在对各个卦象的爻辞解读中的，因为古文的晦涩以及周易的特有诞生过程还有千年的时光阻隔，想一探周易原貌是非常困难的，几千年来不断的有人用不同的方式去解读，然后再用实践去检验这种解读方式对不对... 虽然是笨方法，但实践是检验真理的唯一标准，经过几千年实践总结，总有一些有参考价值的东西会沉淀下来，但不幸的是鱼龙混杂很难分辨～

 

不管白猫花猫能抓住耗子就是好猫～ 这虽然不是真理，但在某些情况下是不得已而为之的无奈选择，既然现代自然科学对未来的预测无能为力，那么就只能求助于经验法则了，虽然这个体系很不稳定，时常出错，而且骗子很多，但是没有别的选择的情况下有总比没有强吧～

 

其实对于宇宙的本质、人生的意义...之类的问题，每个人都保有好奇心与探索欲望，用当前时代所有可能的手段给自己一个答案难道不好吗？当然得到正确答案的可能性很低，但是是否就代表可以不去追求探索了呢？

 

自强不息 厚德载物 是国人永远不应放弃的为人做事准绳...



已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Wed, 02 Jul 2008 16:33:18 +0800 http://finalbone.javaeye.com/blog/210690 http://finalbone.javaeye.com/blog/210690 管窥周易（002） finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/210623  发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

说起周易，很多人马上就会想起预测与占卜，这点不需要回避，在大部分现代人眼中预测与占卜是很没谱的事儿，都骗人的... 之所以会这样是因为现代科学在预测理论与实践方面很薄弱，芸芸众生之中真正懂得独立思考的人很少，大部分都是墙头草，社会氛围也就是这么形成的...

 

预测与评估是一门科学，本人才疏学浅这么高深的东西还是避而不谈的好，在做项目计划的时候也仅仅用到了pert与delphi法做一些进度评估，都是粗浅的皮毛而已～ 说起预测，很多人往往搬出量子力学的测不准原理来说明我们宏观世界的不可预知性，其中的逻辑不知道是怎么样的，至少我看不出这中间的必然联系，所以个人认为谈起日常生活中预测与评估的时候还是不要提什么量子力学吧，多谈谈概率与统计倒是实在一点...

 

周易有人说是哲学，有人说是自然科学，当然也有人说是迷信的玄学。在我看来没有证伪的事物就不忙着定性，就像没宣判的嫌疑人。

 

哲学的诞生必然有着自然科学的基础，归根到底还是自然科学在人脑中的映射与转换，有趣的是虽然哲学是在自然科学基础上诞生的，但哲学是可以超越自然科学发展水平的，也就是说具有前瞻性和指导性，这也就是哲学的最大价值所在。科学是以抽象理论和试验数据为基础的，哲学是以人类感知思考为基础的，它们都可以被实践反复验证。从这个角度来说周易是一门哲学，还达不到自然科学的标准，但是可以指引自然科学的研究方向。

 

说起周易不得不先谈谈先天八卦的推演过程，也就是先天八卦的原理，基于前人的文章我只简要概述一下：

 

1。

“无极生两仪”-- 无极：一个抽象概念，一切事物的初始状态；两仪：阴阳，一切事物的内在对立特性；总的来说就是描述一切事物由无到有的过程。

 

个人认为周易在诞生的时候是没有“无极”这个概念的，只有阴阳，对应人类最基本的感知，日夜、冷暖、冬夏...

 

2。

“两仪生四象”-- 四象：这是人类对事物加深认识的一个过程，使用的是基本的二分法，如果说“无极生两仪”是对事物构成特性做了一个基本了解的话，“两仪生四象”就是对构成事物的基本单元的进一步探究与认识。

 

为了便于理解暂且把四象当作春夏秋冬四季...

 

3。

“四象生八卦”-- 八卦：对四象又用了一次二分法，格物致知也就是如此吧。从发展周易的现实需求来考虑，八卦的诞生就是为了指导农业生产，四象对四季的划分粒度太粗不便使用，于是再次细分。至于后来的历法与24节气都是基于先天八卦的。

 

先天八卦的次序非常简单明了，就是冬夏交替、冷暖交替...

 

学习到这里我对每一卦的名称和爻辞是完全忽略不看的，因为它们会干扰我对周易本质的理解，这些内容是要放到以后再去了解的。

 

先天八卦用数字表示就是一个九宫：

6  1  8

7  5  3

2  9  4

或者

6  7  3

5  #  2

4  0  1

 

我也瞎填一个：

1.5   1  -0.5

1.0   0  -1.0

0.5  -1  -1.5

 

这样填虽然已经不是九宫，但我觉得更好理解，1至阳、-1至阴，阴阳调和后为0，没有必要追求各个方向上的和相等，只要保证以0为中心的各个轴线的两端可以平衡，也就是相加为0。这就是先天八卦。

 

周易给人无限的联想与发挥空间，再此基础上的衍义不计其数，还多少都能靠点谱，这也许就是它能长盛不衰的原因之一吧...

 

我也不能免俗，衍义一下也无妨～ 观察一下先天八卦的四根轴线，不知道别人怎么想，我是觉得这四根轴线可以表示我们的四维空间，阴阳之间的演变是以时间为度量单位的，那么1到-1可以当作时间轴，这很合理，中间的三根轴线用来描述三维空间。从这个角度来说先天八卦就是一个四维空间的事物演变模型，说到这里肯定不少人觉得牵强和穿凿，尽可以无视，呵呵～

 

上一节提到的周易之“乱”，“乱”就乱在不同的人有不同的解读与衍义方式，难辨真伪，太多选择等于没有选择... 但是我相信还是有人对周易进行严密的数理推算的，只有量化的严密的数理推算有了突破，形成了大一统的理论，这种万家争鸣的局面才会结束，就像我上节所说，受限与人类自身的时空特性，可能永远也没有这一天～ 那么就继续自由发挥下去吧...



已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Wed, 02 Jul 2008 15:03:47 +0800 http://finalbone.javaeye.com/blog/210623 http://finalbone.javaeye.com/blog/210623 管窥周易（001） finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/210554  发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

这两天为了给快出生的孩子取名，了解了一下国粹中的各种奇门玄术，周易自然是核心内容。

 

时间有限只是大略的看了几篇文章，对周易的了解只是皮毛上的皮毛，但是记录一下心得还是有必要的，就算是错误的观点。

 

周易--周:宇宙万物、易:变化推演，合一起就是宇宙万物的演变规律。

 

那么这个规律是怎么总结出来的呢？呵呵，这个规律很可能不是总结出来的，更多的可能是上天的眷顾！

 

周易本是无字天书，是古人对天象观测后总结出的规律的原始记录，时空局限性很强，仅仅是用于对特定地理位置、特定气候条件下的农业生产进行指导与参考。所谓饱暖思淫欲，原始生产力条件下，古人想的更多的只能是如何满足最基本的生存需求。

 

就这样在机缘巧合下，中国人的祖先得到了上天的眷顾，灵光乍现的得到了这个万能武器，远比爱因斯坦的质能方程威力大的多！当然在得到它的时候，还不知道它的威力与光辉可以穿越时空照耀大地，直到永远...

 

从此之后华夏儿女炎黄子孙，很好的继承了这个万能武器，并且从中不断的得到新的发现：哇！原来这里也可以用啊！...哇靠！不是吧～这里竟然也可以用！...偶D神啊！计算机、遗传学、理论物理...原来都是偷学我们的万能武器啊...

 

各种玄经秘术如雨后春笋般疯长～ 各代正统学者也对它进行了一次次基于个体认知的批注... 纵观中国几千年历史，周易一直都在“乱”字中浮沉，自然也应它自己定下的铁律...

 

当然古人的智慧是不能小看的，至少不比现代人差。几千年沉淀下来有污泥也有金块，有些金块被污泥包着，拿水冲一冲就能看到金子，有些金块已经和污泥合为一体，不具备炼化的本领是看不到金子的。所以对中国传统文化中用现代科学无法解读部分进行一刀切，是相当愚蠢的！

 

我从小就有一个观念：“唯物主义是极端唯心主义的一种表现形式！”。“物”的本质都没搞清楚就“唯物”，不是极端“唯心”是什么！？人类在不断加深对世界认识的过程中应该始终保持谦逊与包容...

 

受限与人类本身的时空局限性，对世界的认知可能永远都只能是“管窥”，不断探索的过程仅仅是把这根管子扩大一点，自己还在坐井观天的时候就不要笑别人是青蛙了...

 

 



已有 4 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Wed, 02 Jul 2008 13:25:32 +0800 http://finalbone.javaeye.com/blog/210554 http://finalbone.javaeye.com/blog/210554 MANGOS中文问题最懒解决方案 finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/133232  发表时间: 2007年10月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

MANGOS的程序架构没有考虑多语种支持，给我们带来了不少麻烦～

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

目前的做法：

汉化源码－>记事本转存UTF-8－>字符串首尾加空格（UTF-8格式保存）－>VS2003编译－>中文完美显示

此方法只适用于VS2003 (VS2005中文无法完整显示)，操作繁琐，转化后的源码不直观不便修改...

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

本人对C++不太熟，经过一段时间摸索，找到了一个解决此问题的方法，而且对已完成的汉化内容不用做任何修改即可生效，暂且叫最懒解决方案吧 --__--|||

我发现MANGOS向客户端发送文本的都是UTF-8编码的，经过调试发现VS2005编译后的源码在发送前就已经存在问题了，也就是说用VS2005编译的含有外部工具转换后的UTF-8编码的中文字符的源码并不能保证中文部分的完整性，具体内在原因我没有再深入查下去...就算查下去也不太可能修改VS2005的编译方式～～～

验证此问题可用如下代码：

cpp 代码
  1. #include "stdafx.h"   
  2. #include <iostream>
    #include <string>
    #include <windows.h>
    using namespace std;       
  3.   
  4. void UTF_8ToUnicode(wchar_t* pOut,char *pText)   
  5. {   
  6.     char* uchar = (char *)pOut;   
  7.   
  8.     uchar[1] = ((pText[0] & 0x0F) << 4) + ((pText[1] >> 2) & 0x0F);   
  9.     uchar[0] = ((pText[1] & 0x03) << 6) + (pText[2] & 0x3F);   
  10.   
  11.     return;   
  12. }   
  13.   
  14. void UnicodeToUTF_8(char* pOut,wchar_t* pText)   
  15. {   
  16.     char* pchar = (char *)pText;   
  17.   
  18.     pOut[0] = (0xE0 | ((pchar[1] & 0xF0) >> 4));   
  19.     pOut[1] = (0x80 | ((pchar[1] & 0x0F) << 2)) + ((pchar[0] & 0xC0) >> 6);   
  20.     pOut[2] = (0x80 | (pchar[0] & 0x3F));   
  21.   
  22.     return;   
  23. }   
  24.   
  25. void UnicodeToGB2312(char* pOut,wchar_t uData)   
  26. {   
  27.     WideCharToMultiByte(CP_ACP,NULL,&uData,1,pOut,sizeof(wchar_t),NULL,NULL);   
  28.     return;   
  29. }   
  30.   
  31. void Gb2312ToUnicode(wchar_t* pOut,char *gbBuffer)   
  32. {   
  33.     MultiByteToWideChar(CP_ACP,MB_PRECOMPOSED,gbBuffer,2,pOut,1);   
  34.     return ;   
  35. }   
  36.   
  37. void GB2312ToUTF_8(string& pOut,char *pText, int pLen)   
  38. {   
  39.     char buf[4];   
  40.     int nLength = pLen* 3;   
  41.     char* rst = new char[nLength];   
  42.   
  43.     memset(buf,0,4);   
  44.     memset(rst,0,nLength);   
  45.   
  46.     int i = 0;   
  47.     int j = 0;   
  48.     while(i < pLen)   
  49.     {   
  50.         if( *(pText + i) >= 0)   
  51.         {   
  52.             rst[j++] = pText[i++];   
  53.         }   
  54.         else  
  55.         {   
  56.             wchar_t pbuffer;   
  57.             Gb2312ToUnicode(&pbuffer,pText+i);   
  58.   
  59.             UnicodeToUTF_8(buf,&pbuffer);   
  60.   
  61.             unsigned short int tmp = 0;   
  62.             tmp = rst[j] = buf[0];   
  63.             tmp = rst[j+1] = buf[1];   
  64.             tmp = rst[j+2] = buf[2];   
  65.   
  66.             j += 3;   
  67.             i += 2;   
  68.         }   
  69.     }   
  70.     rst[j] = '\0';   
  71.   
  72.     pOut = rst;   
  73.     delete []rst;   
  74.   
  75.     return;   
  76. }   
  77.   
  78. void UTF_8ToGB2312(string &pOut, char *pText, int pLen)   
  79. {   
  80.     char * newBuf = new char[pLen];   
  81.     char Ctemp[4];   
  82.     memset(Ctemp,0,4);   
  83.   
  84.     int i =0;   
  85.     int j = 0;   
  86.   
  87.     while(i < pLen)   
  88.     {   
  89.         if(pText[i] > 0)   
  90.         {   
  91.             newBuf[j++] = pText[i++];   
  92.         }   
  93.         else  
  94.         {   
  95.             WCHAR Wtemp;   
  96.             UTF_8ToUnicode(&Wtemp,pText + i);   
  97.   
  98.             UnicodeToGB2312(Ctemp,Wtemp);   
  99.   
  100.             newBuf[j] = Ctemp[0];   
  101.             newBuf[j + 1] = Ctemp[1];   
  102.   
  103.             i += 3;   
  104.             j += 2;   
  105.         }   
  106.     }   
  107.     newBuf[j] = '\0';   
  108.   
  109.     pOut = newBuf;   
  110.     delete []newBuf;   
  111.   
  112.     return;   
  113. }   
  114.   
  115. int _tmain(int argc, _TCHAR* argv[])   
  116. {   
  117.     string strIN = " 管理员 ";   
  118.     cout << "init 0 : " << strIN << endl;   
  119.     string strOUT;   
  120.     cout << ". GB2312 -> UTF-8  ." << endl;   
  121.     char *chr1 = (char *)strIN.c_str();   
  122.     GB2312ToUTF_8(strOUT, chr1, strlen(chr1));   
  123.     cout << strOUT << endl;   
  124.     cout << ". UTF-8  -> GB2312 ." << endl;   
  125.     // 测试1 （直接在代码中转换并传递）   
  126.     char *chr2 = (char *)strOUT.c_str();   
  127.     UTF_8ToGB2312(strOUT, chr2, strlen(chr2));   
  128.     cout << "test 1 : " << strOUT << endl;   
  129.     // 测试2 （外部工具转换并放入源码）   
  130.     char *chr3 = " 绠＄悊鍛 ";   
  131.     UTF_8ToGB2312(strOUT, chr3, strlen(chr3));   
  132.     cout << "test 2 : " << strOUT << endl;   
  133.     return 0;   
  134. }   

VS2005编译后 test 2 的输出结果并不是“管理员” --__--|||

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

问题找到了，接下来就是解决问题，既然VS2005不能完美编译预先转换后的中文源码，那就改写这部分的处理方式即可。

顺着这条思路我找到了GossipDef.cpp的void PlayerMenu::SendGossipMenu( uint32 TitleTextId, uint64 npcGUID)方法，这是MANGOS服务端向客户端输出对话界面的最终出口，在这里做一些改写即可达到目的，改写后的代码如下：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

cpp 代码
  1. ...   
  2.   
  3. void PlayerMenu::SendGossipMenu( uint32 TitleTextId, uint64 npcGUID )   
  4. {   
  5.     WorldPacket data( SMSG_GOSSIP_MESSAGE, (100) );   
  6.     data << npcGUID;   
  7.     data << uint32( TitleTextId );   
  8.     data << uint32( pGossipMenu->MenuItemCount() );   
  9.   
  10.     for ( unsigned int iI = 0; iI < pGossipMenu->MenuItemCount(); iI++ )   
  11.     {   
  12.         data << uint32( iI );   
  13.         data << uint8( pGossipMenu->GetItem(iI).m_gIcon );   
  14.         data << uint8( pGossipMenu->GetItem(iI).m_gCoded );   
  15.         data << uint32(0);   
  16.   
  17.   
  18.         // Tyre 解决VS2005中文问题 >>>   
  19.         std::string str = pGossipMenu->GetItem(iI).m_gMessage;   
  20.         if(str[0] == ' '){ // 根据首字符是否为空格来判断是否需要转换   
  21.             char *chr = (char *)str.c_str();   
  22.             TyreCodeTransformer::GB2312ToUTF_8(str, chr, strlen(chr));   
  23.         }   
  24.         data << str;   
  25.         // <<< Tyre   
  26.   
  27.   
  28.         data << uint8(0);   
  29.     }   
  30.   
  31.     data << uint32( pQuestMenu->MenuItemCount() );   
  32.   
  33.     for ( uint16 iI = 0; iI < pQuestMenu->MenuItemCount(); iI++ )   
  34.     {   
  35.         uint32 questID = pQuestMenu->GetItem(iI).m_qId;   
  36.         Quest const* pQuest = objmgr.GetQuestTemplate(questID);   
  37.   
  38.         data << questID;   
  39.         data << uint32( pQuestMenu->GetItem(iI).m_qIcon );   
  40.         data << uint32( pQuest ? pQuest->GetQuestLevel() : 0 );   
  41.         std::string Title = pQuest->GetTitle();   
  42.         if (pSession->GetSessionLanguage()>0)   
  43.         {   
  44.             QuestLocale const *ql = objmgr.GetQuestLocale(questID);   
  45.             if (ql)   
  46.             {   
  47.                 if (ql->Title[pSession->GetSessionLanguage()]!="")   
  48.                     Title=ql->Title[pSession->GetSessionLanguage()];   
  49.             }   
  50.         }   
  51.         data << Title;   
  52.     }   
  53.   
  54.     pSession->SendPacket( &data );   
  55. }   
  56.   
  57. ...  

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

大家可能注意到了

if(str[0] == ' '){ // 根据首字符是否为空格来判断是否需要转换

因为PlayerMenu::SendGossipMenu是处理源码与数据库中数据的统一出口，对于原本就是UTF-8编码的数据不能进行再次转换，不然会产生乱码。为了便于区分加上根据之前的习惯，汉化后的字符串前后都已经加上了空格，根据这一特点决定了用此方式来区分是否需要转换，也可以换种方式加上字符串编码分析然后再做区分判断（可扩展为多语种支持），暂时不搞了，以后再说吧～

此方式通过扩展是可以支持多语种的，但是将内容文本HardCode进源码的味道很不好～，还是等待MANGOS团队对代码做整体更新吧，另外MANGOS的文本输出接口可能不只这一个PlayerMenu::SendGossipMenu，等发现了其它接口用同样方法修改即可。。。

呵呵！不求最好！只求最懒！如果有更好的方法请大家和我联系 QQ 15149077 泛开源技术研究群 40635510 ！

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

总结最懒解决方案：

汉化源码－>字符串首加空格(GB2312/UTF-8格式保存)－>VS2003/2005编译－>中文完美显示

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

不知道MANGOS是什么？ 去这里看看就知道了 http://www.mangosproject.org

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Thu, 18 Oct 2007 17:12:17 +0800 http://finalbone.javaeye.com/blog/133232 http://finalbone.javaeye.com/blog/133232 Hibernate与JDBC事务整合 finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/37707  发表时间: 2006年12月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近摸索了一下Hibernate与JDBC(iBATIS)事务整合问题，算是有点收获，写出来和大家讨论一下吧。。。

一般大家都会使用Spring声明型事务 transactionAttributes 为 PROPAGATION_REQUIRED

Hibernate 使用 HibernateTransactionManager 、JDBC(iBATIS) 使用 DataSourceTransactionManager

当需要将它们整合到一个事务中的时候

普通的做法是配置统一的DataSource， Hibernate与JDBC(iBATIS) 都使用HibernateTransactionManager

坛子里有篇帖子已经详细论述了这种整合方案 http://www.javaeye.com/topic/11063?page=2

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Hibernate与JDBC(iBATIS) 都使用DataSourceTransactionManager又可不可以呢？

普遍的看法是 NO！ 认为DataSourceTransactionManager根本就不处理Hibernate的session，事务当然无法实现。。。

但事实是否真的如此呢？

答案同样是 NO！ http://forum.springframework.org/archive/index.php/t-9878.html

Juergen Hoeller：
Just if you proxy your JDBC DataSource with a TransactionAwareDataSourceProxy (available since Spring 1.1 RC1) and pass that proxy to your LocalSessionFactoryBean, you could use DataSourceTransactionManager in combination with Hibernate.

也就是说配置 sessionFactory  的 useTransactionAwareDataSource 为 true

Hibernate与JDBC(iBATIS)  都使用 DataSourceTransactionManager 同样可以保证事务

原理就是保证了 connection 的唯一性。



已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Thu, 07 Dec 2006 09:33:26 +0800 http://finalbone.javaeye.com/blog/37707 http://finalbone.javaeye.com/blog/37707 关于Agile的一些问题 finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/33906  发表时间: 2006年11月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

实施了Agile之后，可能导致项目失败的最大风险是什么？

客户到底应该多大程度的参与开发过程？

当客户需求与公司利益发生冲突该如何解决？

如何持续的改进已有的Agile？

高人员流动率的环境中如何有效的积累知识和技术？

把成本作为参数赋与所有问题，我们得到的答案将会如何？

有些问题只有一个最优解
有些问题存在有限个最优解
有些问题有无穷多个解或者说无解

Agile包含所有这些问题．．．那么我们应该如何评价试图解决所有问题的Agile？

已有 27 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Sun, 12 Nov 2006 19:41:00 +0800 http://finalbone.javaeye.com/blog/33906 http://finalbone.javaeye.com/blog/33906 XP实践的质疑 finalbone 作者: finalbone  链接：http://finalbone.javaeye.com/blog/33903  发表时间: 2006年11月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

１．客户作为团队成员
XP强调面对面的交流，强调物理空间的聚合，但事实是客户与开发团队在物理空间上协同工作基本是不可能的，无论这里的客户是指掏钱买单的还是业务人员．至于寻找可以完全替代客户的人加入团队更是无稽．

２．结对编程
这里又有些过于理想化，同一个项目用两倍的人去完成，除非老板大脑短路，这种不计成本的建议也只能停留在建议的范围内．不要说结对编程可以使开发效率提高一倍或更多，那是不可能的．想要达到结对编程的大部分效果有很多成本更低的方法，比如有计划的互换开发人员角色，畅通无阻碍的团队办公环境．．．

已有 0 人发表留言，猛击->>这里<<-参与讨论


JavaEye推荐



]]> Sun, 12 Nov 2006 18:12:22 +0800 http://finalbone.javaeye.com/blog/33903 http://finalbone.javaeye.com/blog/33903