普元啟動(dòng)服務(wù)失敗的解決方法

1、普元啟動(dòng)服務(wù)失敗的解決方法   當(dāng)多個(gè)人同時(shí)使用一個(gè)數(shù)據(jù)庫的時(shí)候，啟動(dòng)普元控制臺(tái)會(huì)一直停留在rcall，然后顯示一個(gè)超時(shí)的警告，那樣就需要修改一下普元的一個(gè)定時(shí)器配置項(xiàng)。   安裝目錄下PrimetonPlatformapps_configdefaultconfig 中的一個(gè)user-config.xml文件 將下列代碼中高亮字段中的true改為false即可   <module name="Schedule">         &#

2、160; <group name="Default">               <!- IsSchedulerStartoptional,default to "true", whether to start timer when application starts up ->               &

3、#160; <configValue key="IsSchedulerStart">true</configValue>               <!- DataSouceNameoptional,default to "default", datasouce name（must be the same as DataSource's Group name） ->    

4、;           <!- configValue key="DataSouceName">default</configValue->           </group>       </module> 當(dāng)EOS啟動(dòng)調(diào)試服務(wù)時(shí)，控制臺(tái)停留在 RCALL后無反應(yīng)一般是因?yàn)槎〞r(shí)任務(wù)的表被鎖住的原因，可在plsqldevelop

5、er中執(zhí)行以下語句：select 'alter system kill session '''|b.SESSION_ID|','|c.SERIAL#|''' immediate;'from v$locked_object b,v$session cwhere b.SESSION_ID = c.SID將查詢結(jié)果復(fù)制到新的SQL窗口執(zhí)行，執(zhí)行完成后再啟動(dòng)服務(wù)- 解決EOS連接失敗無法啟動(dòng)的問題 - 查看有沒有被鎖的對(duì)象 select * from v$locked_object - 查看被鎖的對(duì)象是哪張表se

6、lect * from dba_objects where object_id in(select t.OBJECT_ID from v$locked_object t)-select * from dba_objects where object_id=73713 - 從菜單欄進(jìn)入Tools/Sessions，將Status='ACTIVE' and Sid=被鎖對(duì)象id的記錄，點(diǎn)擊右鍵菜單中的Kill跟操作系統(tǒng)的兼容性有關(guān)，建議去下看ideeclipseplugins目錄下org.eclipse.swt.win32.win32.x86_3.2.0.和org.eclipse.

7、swt_3.2.0兩個(gè)jar的版本，更換成高版本試試。提供清理eos開發(fā)過程中緩存清理的方法摘要：提供清理eos開發(fā)過程中緩存清理的方法。在eos開發(fā)過程中，經(jīng)常遇到新開發(fā)的代碼無法使用，右鍵部署之后依然使用原來的老舊代碼，非常影響開發(fā)速度。這里提供下清理緩存的方式，確定我們的最新代碼能夠被使用。對(duì)于分組開發(fā)過程中，各人代碼版本差異無法實(shí)現(xiàn)同樣的運(yùn)行效果有特效。1.       刪除%EOS_HOME%apps_configdefaultwork_temp下的所有文件和文件夾。如需使用平臺(tái)的各種日志請(qǐng)酌情備份logs下的內(nèi)容

8、。2.       刪除%EOS_HOME%apache-tomcat-7.0.54work下的所有內(nèi)容，情況tomcat的緩存。3.       刪除%EOS_HOME%apache-tomcat-7.0.54webappsdefaultWEB-INF_srvworkuser下我們自己項(xiàng)目的內(nèi)容。慎重，別刪錯(cuò)了，我們自己開發(fā)的。ESB修改默認(rèn)端口61616windows操作系統(tǒng)下的默認(rèn)的ICS服務(wù)（Internet Connection Sharing）

9、默認(rèn)占用了61616端口，因此要解決jms端口沖突的情況有兩種方式。方式一：  停止ICS服務(wù)。          命令行執(zhí)行 “services.msc”,找到ICS服務(wù)，右鍵停止，并設(shè)置為以后手動(dòng)啟動(dòng)。方式二：修改ESB下JMS默認(rèn)端口。           找到D:PrimetonESBstudioserverEOS_srvconfig下的esb-mq-config.xml和fts-server-config.xml文件，分別修改如下內(nèi)容：    （

10、esb-mq-config.xml)<transportConnectors><transportConnector name="openwire" uri="tcp:/:61616" /></transportConnectors> (fts-server-config.xml)<mqconfig>     <url>tcp:/:61616</url>      <reCon

11、nectTime>5</reConnectTime>      <heartbeat_interval>1</heartbeat_interval>   </mqconfig>  如何修改Platform發(fā)布Webservice服務(wù)的命名空間摘要：如何修改Platform發(fā)布Webservice服務(wù)的命名空間（）為自己指定的名字。問題描述:Platform發(fā)布Webservice服務(wù)，在瀏覽器上查看wsdl，客戶想修改其中的命名空間，如下圖紅色框的內(nèi)容，想更換成自己的命名空間。適用

12、環(huán)境: PlatformV6及以上版本處理經(jīng)驗(yàn): 可以修改user-config.xml中的配置，將DefultNameSpace這行的注釋放開，修改為自己指定的值。<module name="WebService">        <group name="WSDL">            

13、<!-<configValue key="DefultNameSpace">        </group>    </module>應(yīng)用被攔截，調(diào)用報(bào)錯(cuò)無法訪問摘要：應(yīng)用被攔截，調(diào)用報(bào)錯(cuò)無法訪問場(chǎng)景描述： test.html 放在 Tomcat 的 webapps/ROOT 目錄下，或者其他非default應(yīng)用下該靜態(tài) HTML

14、60;頁面中有一個(gè)超鏈接 <a href=":8080/default/" target="_blank">EOS test</a>在資源管理器中直接雙擊該文件，在瀏覽器打開后（file:/ 協(xié)議），點(diǎn)擊該超鏈接可以正常訪問。但如果我通過 :8080/test.html 訪問該頁面（http:/ 協(xié)議），點(diǎn)擊該超鏈接時(shí)，直接報(bào)錯(cuò)了，錯(cuò)誤信息為：調(diào)用異常，請(qǐng)查看日志！而使用window.open沒有問題。

15、<a href="#" onclick="open_win();" >EOS test</a>，<script type="text/javascript">function open_win() window.open(":8080/default/skins/default/index.jsp")</script>情況分析：獲取前后http頭，referer為不同應(yīng)用之間的請(qǐng)求，那么可能被default給攔截了。解決辦法：去

16、除攔截器：把a(bǔ)pps_configdefaultconfig eoshandler-web.xml中的以下配置注釋掉，看看是否還會(huì)不會(huì)有問題：    <handler id="HttpRefererWebInterceptor"sortIdx="3"pattern="/*" class="com.eos.access.http.security.HttpRefererWebInterceptor"/>摘要：EOS工程部署到JBOSS后報(bào)錯(cuò)。分析日后初步確定為 "j

17、boss-6.1.0.Finalcommonlibslf4j-api.jar"與"jboss-6.1.0.Finalserverdefaultdeploydefault.eardefault.warWEB-INFlibslf4j-api-1.5.6.jar" 沖突導(dǎo)致該問題已經(jīng)解決。方案如下： 修改 jbossserverdefaultdeployersjbossweb.deployerMETA-INFwar-deployers-jboss-beans.xml  添加org.slf4j，以過濾該包代碼如下：1. <!- Allo

18、w for war local class loaders: in testing ->  2.   <bean name="WarClassLoaderDeployer" class="org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer">  3.      

19、;<property name="relativeOrder">-1</property>  4.   <property name="filteredPackages">javax.servlet,mons.logging,org.slf4j</property>         5.   </bean>  

20、;然后重啟JBOSS服務(wù)器。原因分析：   jboss加載jar包順序問題。摘要：在最近修改SSO應(yīng)用的時(shí)候，涉及到需要在jar包中讀取工程配置文件的問題。在jar包中，讀取配置文件，需要單獨(dú)處理。項(xiàng)目中的一些配置文件，如perties log4j.xml 不想打包進(jìn)jar。因?yàn)榭赡軙?huì)修改其中的一些配置信息，打包進(jìn)jar，就變得比較笨拙，不方便修改文件?？梢杂萌缦路绞?，實(shí)現(xiàn)在jar包中讀取外部配置文件。方法一：關(guān)鍵代碼。讀取properties文件方法：InputStream ins = getClass().getRe

21、sourceAsStream("/resource/perties"); 但是log4j.xml 又需要單獨(dú)處理：PropertyConfigurator.configure(System.getProperty("user.dir") + "/resource/log4j.xml"); 方法二：配置文件perties和jiar包在同一個(gè)目錄下面：FileInputStream inputStream1 = new F

22、ileInputStream("perties");  配置文件perties在jar包內(nèi)部：InputStream inputStream2 = a.class.getResourceAsStream("/perties");org.apache.axis2.AxisFault: WSDoAllReceiver:摘要：使用EOS7.2自動(dòng)生成的客戶端代碼，在調(diào)用帶有安全頭部消息的webservice接口的時(shí)候，會(huì)經(jīng)常出現(xiàn) org.apache.axis2.AxisFault:

23、 WSDoAllReceiver: Incoming message does not contain required Security header的異常，可以照下文處理使用EOS7.2自動(dòng)生成的客戶端代碼，在調(diào)用帶有安全頭部消息的webservice接口的時(shí)候，會(huì)經(jīng)常出現(xiàn) org.apache.axis2.AxisFault: WSDoAllReceiver: Incoming message does not contain required Security header的異常，表示傳入的消息不包含所需的安全報(bào)頭，經(jīng)過分析發(fā)現(xiàn)是該方法在第一次被調(diào)用后，已經(jīng)生成了一些安全校驗(yàn)數(shù)據(jù)，Li

24、stenerManager.defaultConfigurationContext不為空，無法對(duì)新的請(qǐng)求進(jìn)行安全數(shù)據(jù)的封裝，導(dǎo)致請(qǐng)求失敗，應(yīng)該清空ListenerManager.defaultConfigurationContext應(yīng)用環(huán)境，重新生成對(duì)應(yīng)的安全校驗(yàn)數(shù)據(jù)?？梢哉杖缦路绞竭M(jìn)行處理。在使用客戶端代碼的方法中，加入ListenerManager.defaultConfigurationContext = null;用于清空運(yùn)行環(huán)境，以對(duì)新的請(qǐng)求，作出新的安全設(shè)置。示例代碼片段：Bizletpublic Map sellOrderPriceUpdate(SellOrderImpl sel

25、lOrderImpl,SellOrderDetailImpl sellOrderDetailImpls) throws Exception ListenerManager.defaultConfigurationContext = null;   /重置axis2部分運(yùn)行參數(shù)環(huán)境，用于新的請(qǐng)求ZCOP_SERVICEStub.ZifSoChange in=new ZCOP_SERVICEStub.ZifSoChange();  /輸入ZifSoChangeResponse response=new ZCOP_SERVICEStub.ZifSoChange

26、Response();/輸出EOS在業(yè)務(wù)程序中獲取邏輯構(gòu)件執(zhí)行的SQL語句文章 > huangxu > 文章詳情EOS在業(yè)務(wù)程序中獲取邏輯構(gòu)件執(zhí)行的SQL語句  huangxu  發(fā)表于 3個(gè)月前  來自話題 #應(yīng)用開發(fā)平臺(tái)（EOS Platform）#  · 90 瀏覽摘要：更改log4j的日志配置，使用類繼承方式，方法重寫，在程序中獲取邏輯流執(zhí)行SQL。 配置文件：應(yīng)用配置目錄 /log4j-sys.xml (可根據(jù)實(shí)際情況使用更改具體配置

27、文件)；更改log4j的日志配置，使用類繼承方式，方法重寫，在程序中獲取邏輯流執(zhí)行SQL。配置文件：應(yīng)用配置目錄    /log4j-sys.xml  (可根據(jù)實(shí)際情況使用更改具體配置文件)；配置文件說明：config/log4j-deploy.xml   部署日志   記錄系統(tǒng)啟動(dòng)、停止、構(gòu)件包部署、集群通知等信息的日志。config/log4j-trace.xml      跟蹤日志   Server引擎的調(diào)試日志，用于系統(tǒng)維護(hù)人員定位系統(tǒng)運(yùn)行問題使用。config/log4j-sys.xml

28、60;      系統(tǒng)日志    大粒度的引擎運(yùn)行的入口、出口的日志，用于調(diào)用棧分析，可以進(jìn)行性能分析使用config/log4j-engine.xml   引擎日志    細(xì)粒度的引擎運(yùn)行日志，可以打印上下文數(shù)據(jù)，用于定位業(yè)務(wù)問題。記錄時(shí)機(jī)：頁面流(P)執(zhí)行、邏輯流(B)執(zhí)行、服務(wù)(S)執(zhí)行、Web服務(wù)(W)調(diào)用、定時(shí)任務(wù)(D)執(zhí)行、JSP(J)執(zhí)行、SQL(Q)執(zhí)行（超過時(shí)限者記錄）、運(yùn)算邏輯(X)執(zhí)行（超過時(shí)限者記錄）；記錄格式：有固定格式記錄時(shí)間請(qǐng)求編號(hào)P|B|S|W|D|J|Q|X(類型)Begin|En

29、d|Exception|Run全名執(zhí)行時(shí)長(zhǎng)父全名IP地址登錄用戶ID登錄用戶名當(dāng)前內(nèi)存總量當(dāng)前空閑內(nèi)存量自定義信息。配置文件log4j-sys.xml  ，找到log.sys.sql開關(guān)，<level value="off"/>off更改為all找到RollingFileAppender新建新類LimsLogOut繼承RollingFileAppender，重寫doAppend方法，方法參數(shù)LoggingEvent 內(nèi)有屬性可區(qū)分SQL。截圖實(shí)例如下：由于該類記錄SQL日志為超過時(shí)限者記錄，時(shí)限默認(rèn)設(shè)置為1000毫秒，很多sql執(zhí)行時(shí)間可能不需要100

30、0毫秒，需進(jìn)行更改，找到sys-config.xml 配置文件，將屬性LogSqlWhenTimeout設(shè)置為1。部署配置文件，在新建類LIMSLogOut中可以處理SQL日志。多個(gè)EOS連接同一個(gè)數(shù)據(jù)庫出現(xiàn)定時(shí)器表鎖定的問題解決方案文章 > bigdabao > 文章詳情多個(gè)EOS連接同一個(gè)數(shù)據(jù)庫出現(xiàn)定時(shí)器表鎖定的問題解決方案  bigdabao  發(fā)表于 4個(gè)月前  來自話題 #應(yīng)用開發(fā)平臺(tái)（EOS Platform）#  · 260 瀏覽

31、摘要：多個(gè)EOS連接同一個(gè)數(shù)據(jù)庫出現(xiàn)定時(shí)器表鎖定的問題解決方案問題描述： 如果多個(gè)EOS連接同一個(gè)數(shù)據(jù)庫，在server啟動(dòng)的時(shí)候，會(huì)出現(xiàn)EOS_QRTZ_LOCKS鎖表的情況，導(dǎo)致Server啟動(dòng)不成功解決方案：   多個(gè)環(huán)境連通過庫，容易出現(xiàn)定時(shí)器鎖表的問題，因?yàn)槎〞r(shí)器默認(rèn)情況下是啟動(dòng)，可嘗試如下操作： <module name="Schedule"> <group name="Default"> <!- IsSchedulerStartoptional,default to &q

32、uot;true", whether to start timer when application starts up -> <configValue key="IsSchedulerStart">true</configValue> <!- DataSouceNameoptional,default to "default", datasouce name（must be the same as DataSource's Group name） -> <!- configValue k

33、ey="DataSouceName">default</configValue-> </group> </module> 將顏色標(biāo)記的true改為false（連同一個(gè)庫的每個(gè)環(huán)境都需要改）用戶session失效，ajax調(diào)用不能跳轉(zhuǎn)的解決方案文章 > liucl > 文章詳情用戶session失效，ajax調(diào)用不能跳轉(zhuǎn)的解決方案(Primeton EOS)  liucl  發(fā)表于 9個(gè)月前  來自話題 #應(yīng)用開發(fā)平臺(tái)（EOS Pla

34、tform）#  · 341 瀏覽摘要：在某客戶項(xiàng)目支持過程中發(fā)現(xiàn)session失效后，ajax還能繼續(xù)調(diào)用，原因是在攔截器雖然能攔截到ajax調(diào)用，也做了跳轉(zhuǎn)到index.jsp的操作，但由于是ajax調(diào)用，在index.jsp中并不能完成跳轉(zhuǎn)，頁面沒有任何變化，所以不能正常跳轉(zhuǎn)到登錄頁面，在abframe或其它項(xiàng)目可能也存在這種問題。場(chǎng)景一個(gè)基于Ajax技術(shù)的Web應(yīng)用，采用的是多頁面方式 ，每個(gè)頁面內(nèi)部使用Ajax實(shí)現(xiàn)復(fù)雜業(yè)務(wù)邏輯之間的無刷新切換，使用了Struts來實(shí)現(xiàn)MVC。問題對(duì)于Ajax請(qǐng)求，只有在通過用戶驗(yàn)證無誤之后才能對(duì)請(qǐng)求作

35、出響應(yīng)。如果用戶長(zhǎng)時(shí)間不做操作導(dǎo)致Session過時(shí)之后才發(fā)出請(qǐng)求，則此時(shí)應(yīng)該跳轉(zhuǎn)到出錯(cuò)頁面，提示用戶重新登錄。對(duì)于非Ajax請(qǐng)求，可以自定義異常并針對(duì)此異常設(shè)置相應(yīng)的出錯(cuò)頁面。在用戶信息驗(yàn)證失敗的時(shí)候直接拋出此異常即可，web容器會(huì)自動(dòng)捕捉到此異常并且顯示出錯(cuò)頁面；但是，對(duì)于Ajax請(qǐng)求，則不會(huì)如期待的那樣自動(dòng)跳轉(zhuǎn)到出錯(cuò)頁面。若不錯(cuò)特殊處理，Ajax請(qǐng)求的回調(diào)函數(shù)會(huì)得到意想不到的數(shù)據(jù)而導(dǎo)致程序出錯(cuò)。分析對(duì)于一個(gè)Ajax的應(yīng)用，每一次客戶端和服務(wù)器的數(shù)據(jù)交互，可以看成是在一個(gè)由客戶端的XMLHttpRequest和服務(wù)器端的Servlet(這里假設(shè)用Servlet響應(yīng)Ajax請(qǐng)求)組成的閉合管

36、道。解決在Filter中，判斷當(dāng)前用戶是否處理登錄狀態(tài)，如果session已經(jīng)失效則調(diào)用response.getWriter.write("session_time_out");修改eos-ajax.js內(nèi)容，判斷返回的ajax.responseText的內(nèi)容是否為"session_time_out"，如果相等，則認(rèn)為session已經(jīng)失效并調(diào)用top.location = "auth/login.jsp"；注意eos-ajax.js是平臺(tái)js庫文件，所以像"auth/login.jsp"這樣的項(xiàng)目路徑最后采用配置

37、的方式。總結(jié)對(duì)于Ajax的請(qǐng)求，其數(shù)據(jù)流是封閉的，服務(wù)器發(fā)送給在客戶端的數(shù)據(jù)都被XMLHttpRequest對(duì)象所獲得。本文通過從Filter中發(fā)出javascript代碼讓其在客戶端得到執(zhí)行，從而可以在session過時(shí)驗(yàn)證用戶信息失敗之后，讓客戶端自動(dòng)跳轉(zhuǎn)到登錄頁面，與非Ajax請(qǐng)求時(shí)的客戶體驗(yàn)相一致。對(duì)于Ajax請(qǐng)求，此方法進(jìn)一步推廣，可以直接在服務(wù)器端發(fā)出javascript讓其在客戶端得到執(zhí)行。FTP大數(shù)據(jù)解決方案某客戶系統(tǒng)EOS Platform流程數(shù)據(jù)丟失問題定位以及故障排除過程文章 > yang-yong > 文章詳情某客戶系

38、統(tǒng)EOS Platform流程數(shù)據(jù)丟失問題定位以及故障排除過程  yang-yong  發(fā)表于 9個(gè)月前  來自話題 #應(yīng)用開發(fā)平臺(tái)（EOS Platform）#  · 88 瀏覽摘要：從解決問題的角度，我們不建議用戶直接將Connection的autoCommit設(shè)置為false，理由就是這樣破壞了數(shù)據(jù)庫連接；如果用戶需要將連接設(shè)置為false，則需要在用完連接后，將連接的狀態(tài)設(shè)置回去；或者直接在外層使用事務(wù)。一.客戶環(huán)境產(chǎn)品版本：EOS Platform 6.5服務(wù)器：Was7，4個(gè)節(jié)點(diǎn)的集

39、群數(shù)據(jù)庫：Oracle11gJDK版本：1.6瀏覽器：IE7二.問題描述客戶環(huán)境上主要表現(xiàn)為通過邏輯流調(diào)用了BPS的服務(wù)，同時(shí)在邏輯流里面存在業(yè)務(wù)數(shù)據(jù)的操作，調(diào)用完邏輯流之后，流程數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)都丟失了，且整個(gè)過程沒有拋出異常，問題只是偶然重現(xiàn)，而且只能在正式環(huán)境上重現(xiàn)，測(cè)試環(huán)境始終沒有重現(xiàn)問題。三.問題分析定位過程1.熟悉客戶系統(tǒng)，了解問題重現(xiàn)方式，發(fā)現(xiàn)流程數(shù)據(jù)丟失需要客戶操作很多次才會(huì)出現(xiàn)一次，重現(xiàn)概率比較低；2.熟悉客戶代碼，發(fā)現(xiàn)客戶的邏輯流里面存在嵌套事務(wù)，且業(yè)務(wù)操作和流程操作在同一個(gè)事務(wù)里面，對(duì)流程的操作在一個(gè)子事務(wù)里面，邏輯流里面事務(wù)設(shè)置都是接收外部事務(wù)，且同步j(luò)oin方式執(zhí)行，沒

40、有新開事務(wù)的情況，也不存在事務(wù)圖元不匹配的情況。3.分析報(bào)錯(cuò)后的錯(cuò)誤日志，發(fā)現(xiàn)錯(cuò)誤是從事務(wù)同步器里面拋出來的，原因是queryWorkItemDetail報(bào)錯(cuò)，即找不到工作項(xiàng)；正常的情況下，工作項(xiàng)不可能不存在，因?yàn)閳?zhí)行到事務(wù)同步器的時(shí)候，事務(wù)必定已經(jīng)提交了，而此時(shí)查詢工作項(xiàng)肯定可以查詢到，但是目前的錯(cuò)誤情況下，工作項(xiàng)不存在，即根據(jù)錯(cuò)誤日志可以推斷出：事務(wù)已經(jīng)提交，但是數(shù)據(jù)沒有入庫。4.一開始對(duì)事務(wù)同步器理解不夠深刻，以為用戶調(diào)用了事務(wù)管理器的commit操作就會(huì)觸發(fā)同步器的方法，所以一開始懷疑用戶可能是事務(wù)使用不當(dāng)，事務(wù)管理器的begin, commit不匹配之類的情況導(dǎo)致事務(wù)沒有正真提交，數(shù)

41、據(jù)沒有入庫，所以需要驗(yàn)證用戶是不是正真做了事務(wù)提交；5.驗(yàn)證事務(wù)是不是正真做了提交：添加日志，在邏輯流里面的事務(wù)提交圖元前后打印出事務(wù)狀態(tài)，通過這個(gè)狀態(tài)就能判斷出事務(wù)管理器方法是不是存在不匹配的情況，同時(shí)在事務(wù)同步器里面打印出流程實(shí)例，活動(dòng)實(shí)例，工作項(xiàng)實(shí)例的ID以及狀態(tài)，線程ID，請(qǐng)求ID之類的信息，方便問題重現(xiàn)后定位問題；我們判斷事務(wù)狀態(tài)的目的是：如果用戶正真做了提交，而數(shù)據(jù)沒有入庫，說明和產(chǎn)品存在一定關(guān)系，如果用戶沒有做事務(wù)提交，則是用戶代碼的問題，這樣我們就可以根據(jù)這個(gè)狀態(tài)進(jìn)行2個(gè)大的方向定位。6.分析錯(cuò)誤日志，對(duì)比正確情況和錯(cuò)誤情況，發(fā)現(xiàn)打印出的事務(wù)狀態(tài)2種情況是一樣的，提交前是活動(dòng)狀

42、態(tài)，提交后是無事務(wù)狀態(tài)，說明用戶正真做了事務(wù)提交，即用戶使用的事務(wù)管理器begin，commit是匹配的；而且分析事務(wù)同步器里面打印出的流程實(shí)例，活動(dòng)實(shí)例，工作項(xiàng)實(shí)例ID及狀態(tài)也都是一樣的，不存在異常情況，但是數(shù)據(jù)就是沒有進(jìn)入到數(shù)據(jù)庫；7.由于事務(wù)管理器的使用方式?jīng)]有問題，問題又回到原點(diǎn)；后續(xù)只能通過大量重現(xiàn)問題，仔細(xì)分析日志，看還能否找到其他的蛛絲馬跡；由于這個(gè)問題是偶然重現(xiàn)，所以我們懷疑可能跟線程是否有關(guān)系，我們拿到大量的錯(cuò)誤日志后，仔細(xì)查找這個(gè)問題是否和線程相關(guān)，發(fā)現(xiàn)他們存在一定的聯(lián)系，我們分析日志得到規(guī)律是：如果一個(gè)線程出錯(cuò)后，后面所有由這個(gè)線程處理的邏輯流，流程數(shù)據(jù)都丟失，且有一個(gè)線

43、程丟失的流程數(shù)據(jù)達(dá)8次之多；8.由于客戶現(xiàn)場(chǎng)不能對(duì)正式環(huán)境進(jìn)行遠(yuǎn)程調(diào)試，再加上測(cè)試環(huán)境一直重現(xiàn)不了，所以即使我們懷疑是線程問題，但是也無法進(jìn)一步走下去。9.經(jīng)過討論會(huì)之后，我們開始定位數(shù)據(jù)庫連接是否存在問題；后續(xù)我們還是通過打日志的方式來判斷連接是否存在問題；我們?cè)贐PS獲取連接的入口打印連接的實(shí)現(xiàn)類，連接的狀態(tài)等信息；同時(shí)在事務(wù)管理器里面增加日志，在連接的setAutoCommit,close, commit方法上增加日志；10.分析日志：對(duì)比正確日志和錯(cuò)誤日志可以發(fā)現(xiàn)，正確情況下，Connection的autoCommit狀態(tài)是true，錯(cuò)誤情況下，Connection的autoCommi

44、t狀態(tài)是false；在正確情況下，Connection的autoCommit狀態(tài)是true，我們懷疑用戶的was環(huán)境存在問題，因?yàn)镃onnection受事務(wù)管理之后，autoCommit狀態(tài)一定是false，所以我們驗(yàn)證用戶的環(huán)境是否是正常的；我們使用JSP做了最簡(jiǎn)單的驗(yàn)證：開啟事務(wù)，拿到連接，執(zhí)行第一條sql，然后執(zhí)行第二條sql，然后拋出異常，然后再執(zhí)行第3條sql，最后提交，拋出異常則回滾，部署到用戶的測(cè)試機(jī)器上驗(yàn)證，發(fā)現(xiàn)客戶的服務(wù)器并沒有回滾，前2條數(shù)據(jù)入庫了；所以我們斷定客戶的環(huán)境出了問題。11.后面一天我們都在修改was服務(wù)的配置，以為是數(shù)據(jù)源配置錯(cuò)了，導(dǎo)致數(shù)據(jù)庫連接不受事務(wù)管理；

45、折騰了一天之后，最后發(fā)現(xiàn)was環(huán)境下，即使外部開了事務(wù)，Connection的autoCommit狀態(tài)就是true，不像tomcat，Connection受事務(wù)管理之后，autoCommit是false；12.根據(jù)日志，如果說Connection的autoCommit狀態(tài)是true是正確的，那么Connection的狀態(tài)是false則可能就會(huì)存在問題；因?yàn)檎_日志和錯(cuò)誤日志只有這個(gè)地方存在區(qū)別；所以這個(gè)時(shí)候我們懷疑是連接壞了；繼續(xù)分析日志，發(fā)現(xiàn)日志里面有在邏輯流里面調(diào)用了setAutoCommit的方法，用戶代碼將autoCommit屬性設(shè)置了false，所以我們?nèi)プ卟橛脩舸a，找到調(diào)用set

46、AutoCommit的地方。四.解決問題1.找到用戶代碼之后，詢問當(dāng)事人為什么需要將Connection設(shè)置成false，當(dāng)事人也說不出正確的理由，而且還說這個(gè)可以去掉，他只是復(fù)制的；所以我們將這行代碼注釋好之后，部署到測(cè)試服務(wù)器驗(yàn)證；同時(shí)驗(yàn)證打補(bǔ)丁之前和打補(bǔ)丁之后的測(cè)試環(huán)境，此時(shí)，則是環(huán)境能重現(xiàn)問題了，然后打上補(bǔ)丁之后，問題未能重現(xiàn)。第二天將補(bǔ)丁打到生產(chǎn)環(huán)境，問題也未能重現(xiàn)，問題即解決。2.在問題的驗(yàn)證過程中，有人提出，在was容器下，Connection的autoCommit狀態(tài)無論是true或者false對(duì)事務(wù)管理器沒有任何影響，因?yàn)橥ㄟ^走j2ee事務(wù)的標(biāo)準(zhǔn)接口，在was容器下，無論au

47、toCommit的狀態(tài)是true還是false，事務(wù)管理器都是正常的；3.第二天我們對(duì)這一問題進(jìn)行了驗(yàn)證，發(fā)現(xiàn)在was環(huán)境下，通過j2ee事務(wù)的標(biāo)準(zhǔn)接口使用事務(wù)，Connection的autoCommit狀態(tài)true或者false，標(biāo)準(zhǔn)接口的事務(wù)確實(shí)不受影響；所以從另一個(gè)方面來說，eos的事務(wù)管理器對(duì)Connection的autoCommit狀態(tài)為false這種情況支持的不夠完善；五.結(jié)論1.從解決問題的角度，我們不建議用戶直接將Connection的autoCommit設(shè)置為false，理由就是這樣破壞了數(shù)據(jù)庫連接；如果用戶需要將連接設(shè)置為false，則需要在用完連接后，將連接的狀態(tài)設(shè)置回去

48、；或者直接在外層使用事務(wù)。2.從產(chǎn)品的角度，由于標(biāo)準(zhǔn)接口true或者false2種情況都支持，所以也可以說是EOS的事務(wù)管理器支持的不完善，在特定的環(huán)境下，事務(wù)管理器應(yīng)該支持這2種情況。EOS6中配置C3P0數(shù)據(jù)源自動(dòng)重連方案文章 > hanning > 文章詳情EOS6中配置C3P0數(shù)據(jù)源自動(dòng)重連方案  hanning  發(fā)表于 9個(gè)月前  來自話題 #應(yīng)用開發(fā)平臺(tái)（EOS Platform）#  · 116 瀏覽【適用范圍】 EOS6.0、

49、Tomcat、Jboss、Oracle【問題描述和定位】 在使用EOS6.0的時(shí)候，啟動(dòng)了Server后，如果網(wǎng)絡(luò)出現(xiàn)問題Connection reset異常，Oracle數(shù)據(jù)庫連接斷了后就不能進(jìn)行操作了，需要重新啟動(dòng)Server。那么，怎樣配置可以避免重啟Server，特別對(duì)于生產(chǎn)環(huán)境而言，需要盡可能的避免重啟?！窘鉀Q方案和步驟】1、Tomcat：在EOS Governor控制臺(tái)的配置->數(shù)據(jù)源中，選中某數(shù)據(jù)源，點(diǎn)擊修改，將“連接重試次數(shù)”默認(rèn)值-1修改為1，點(diǎn)擊“確定”保存。重啟Server。    或者直接修改目錄D:primetonfor3207_platfo

50、rmeosserverworkingeos-defaultconfig下user-config.xml文件中DataSource的配置：  <configValue key="Retry-Connect-Count">-1</configValue>修改為    <configValue key="Retry-Connect-Count">1</configValue>2、JBoss：修改$JBOSS_HOMEserverdefaultdeploy下的EOSProductDat

51、aSource-ds.xml，將默認(rèn)的數(shù)據(jù)源配置改成如下（與EOS5環(huán)境下配置類似）：<local-tx-datasource> <jndi-name>EOSDefaultDataSource</jndi-name> <connection-url>jdbc:oracle:thin:23:1521:pso</connection-url><driver-class>oracle.jdbc.driver.OracleDriver</driver-class> <connection-p

52、roperty name="user">eos60</connection-property> <connection-property name="password">eos60</connection-property> <min-pool-size>5</min-pool-size> <max-pool-size>100</max-pool-size> <blocking-timeout-millis>5000</blocking-timeo

53、ut-millis> <idle-timeout-minutes>15</idle-timeout-minutes> <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name> <check-valid-connection-sql>select 1 from dual</check-valid-co

54、nnection-sql><new-connection-sql>select 1 from dual</new-connection-sql> </local-tx-datasource>【備注】修改這個(gè)配置還可以解決如果系統(tǒng)中需要多數(shù)據(jù)源的話，在這個(gè)文件中增加一個(gè)local-tx-datasource 配置；上面的配置可能對(duì)系統(tǒng)訪問數(shù)據(jù)庫的性能有影響，有可能每次拿數(shù)據(jù)庫連接的時(shí)候都會(huì)自動(dòng)調(diào)用這個(gè)sql語句；Weblogic、Websphere等應(yīng)用服務(wù)器也應(yīng)該提供了類似的自動(dòng)重連機(jī)制，可以進(jìn)到它們的控制臺(tái)查看。EOS異常處理方法異常獲取EOS的異常

55、獲取分為兩種，一種是在邏輯流中獲取異常，另一種是在java代碼中獲取異常。1.在邏輯流中獲取異常如上圖所示，開發(fā)人員需要在特定的圖元上通過添加異常線并添加異常拋出圖元（在左側(cè)工具面板中的高級(jí)中）的方式來獲取特定的異常信息。 異常拋出圖元需要開發(fā)人員先在構(gòu)件包的配置文件中加入自定義的異常信息，對(duì)圖元進(jìn)行配置是選擇相對(duì)應(yīng)的ERRORCODE和ERRORMESSAGE。ERRORMESSAGE可以定義變量，以0,1的方式來進(jìn)行變量綁定。配置文件路徑：配置/resources/exception/perties。該配置支持中文并自動(dòng)轉(zhuǎn)碼，同樣在也支持國(guó)際化的配置。對(duì)

56、于異常處理圖元更詳細(xì)的說明可以在EOS Studio的幫助文檔中找到，具體路徑：EOS 幫助文檔->技術(shù)參考->EOS基礎(chǔ)參考手冊(cè)->邏輯流->邏輯流編輯器->異常拋出。 2.在java代碼中獲取異常EOS提供了默認(rèn)實(shí)現(xiàn)的EOSException。當(dāng)特定的springbean或者運(yùn)算邏輯圖元需要拋出異常，可以直接在代碼中通過new EOSException的方式來拋出異常。該異常提供了多種構(gòu)造方法，常用的是EOSException(java.lang.String code, java.lang.Object params)。Code是在配置文

57、件中已經(jīng)配置好的，params參數(shù)包含了message中的變量綁定。 異常處理這里只介紹ajax調(diào)用邏輯流返回異常處理的方式。首先，當(dāng)ajax調(diào)用邏輯流時(shí)邏輯流發(fā)生異常，ajax仍然會(huì)執(zhí)行成功。因此異常的捕獲會(huì)在success事件中進(jìn)行。另外exception對(duì)象中的message包含了所有的異常信息，所以需要對(duì)message進(jìn)行處理。EOS拋出的異常默認(rèn)會(huì)使用換行符分隔。處理示例如下：nui.ajax(        url: "com.shghtd.realestate.rule.RuleManage

58、r.getDecisionI.ext",        type: "POST",        cache: false,        success: function(text)            

59、if(typeof(text.exception) = "undefined")                alert("do Success!");            else         

60、60;      var message = text.exception.message;                var strs = message.split("n");                alert(strs0+"n"+strs1);