对于Ajax的请求，其数据流是封闭的，服务器发送给在客户端的数据都被XMLHttpRequest对象所获得。本文通过从Filter中发出javascript代码让其在客户端得到执行，从而可以在session过时验证用户信息失败之后，让客户端自动跳转到登录页面，与非Ajax请求时的客户体验相一致。对于Ajax请求，此方法进一步推广，可以直接在服务器端发出javascript让其在客户端得到执行。
FTP大数据解决方案
http://p.primeton.com/articles/53c8c681e13823343b0000e3
某客户系统EOS Platform流程数据丢失问题定位以及故障排除过程
文章 > yang-yong > 文章详情
某客户系统EOS Platform流程数据丢失问题定位以及故障排除过程
yang-yong 发表于 9个月前 来自话题 #应用开发平台（EOS Platform）# · 88 浏览
摘要：从解决问题的角度，我们不建议用户直接将Connection的autoCommit设置为false，理由就是这样破坏了数据库连接；如果用户需要将连接设置为false，则需要在用完连接后，将连接的状态设置回去；或者直接在外层使用事务。 一.客户环境
产品版本：EOS Platform 6.5 服务器：Was7，4个节点的集群 数据库：Oracle11g JDK版本：1.6 浏览器：IE7
二.问题描述
客户环境上主要表现为通过逻辑流调用了BPS的服务，同时在逻辑流里面存在业务数据的操作，调用完逻辑流之后，流程数据和业务数据都丢失了，且整个过程没有抛出异常，问题只是偶然重现，而且只能在正式环境上重现，测试环境始终没有重现问题。
三.问题分析定位过程
1.熟悉客户系统，了解问题重现方式，发现流程数据丢失需要客户操作很多次才会出现一次，重现概率比较低；
2.熟悉客户代码，发现客户的逻辑流里面存在嵌套事务，且业务操作和流程操作在同一个事务里面，对流程的操作在一个子事务里面，逻辑流里面事务设置都是接收外部事务，且同步join方式执行，没有新开事务的情况，也不存在事务图元不匹配的情况。
3.分析报错后的错误日志，发现错误是从事务同步器里面抛出来的，原因是
queryWorkItemDetail报错，即找不到工作项；正常的情况下，工作项不可能不存在，因为执行到事务同步器的时候，事务必定已经提交了，而此时查询工作项肯定可以查询到，但是目前的错误情况下，工作项不存在，即根据错误日志可以推断出：事务已经提交，但是数据没有入库。
4.一开始对事务同步器理解不够深刻，以为用户调用了事务管理器的commit操作就会触发同步器的方法，所以一开始怀疑用户可能是事务使用不当，事务管理器的begin, commit不匹配之类的情况导致事务没有正真提交，数据没有入库，所以需要验证用户是不是正真做了事务提交；
5.验证事务是不是正真做了提交：添加日志，在逻辑流里面的事务提交图元前后打印出事务状态，通过这个状态就能判断出事务管理器方法是不是存在不匹配的情况，同时在事务同步器里面打印出流程实例，活动实例，工作项实例的ID以及状态，线程ID，请求ID之类的信息，方便问题重现后定位问题；我们判断事务状态的目的是：如果用户正真做了提交，而数据没有入库，说明和产品存在一定关系，如果用户没有做事务提交，则是用户代码的问题，这样我们就可以根据这个状态进行2个大的方向定位。
6.分析错误日志，对比正确情况和错误情况，发现打印出的事务状态2种情况是一样的，提交前是活动状态，提交后是无事务状态，说明用户正真做了事务提交，即用户使用的事务管理器begin，commit是匹配的；而且分析事务同步器里面打印出的流程实例，活动实例，工作项实例ID及状态也都是一样的，不存在异常情况，但是数据就是没有进入到数据库；
7.由于事务管理器的使用方式没有问题，问题又回到原点；后续只能通过大量重现问题，仔细分析日志，看还能否找到其他的蛛丝马迹；由于这个问题是偶然重现，所以我们怀疑可能跟线程是否有关系，我们拿到大量的错误日志后，仔细查找这个问题是否和线程相关，发现他们存在一定的联系，我们分析日志得到规律是：如果一个线程出错后，后面所有由这个线程处理的逻辑流，流程数据都丢失，且有一个线程丢失的流程数据达8次之多；
8.由于客户现场不能对正式环境进行远程调试，再加上测试环境一直重现不了，所以即使我们怀疑是线程问题，但是也无法进一步走下去。
9.经过讨论会之后，我们开始定位数据库连接是否存在问题；后续我们还是通过打日志的方式来判断连接是否存在问题；我们在BPS获取连接的入口打印连接的实现类，连接的状态等信息；同时在事务管理器里面增加日志，在连接的setAutoCommit,close, commit方法上增加日志；
10.分析日志：对比正确日志和错误日志可以发现，正确情况下，Connection的autoCommit状态是true，错误情况下，Connection的autoCommit状态是false；在正确情况下，Connection的autoCommit状态是true，我们怀疑用户的was环境存在问题，因为Connection受事务管理之后，autoCommit状态一定是false，所以我们验证用户的环境是否是正常的；我们使用JSP做了最简单的验证：开启事务，拿到连接，执行第一条sql，然后执行第二条sql，然后抛出异常，然后再执行第3条sql，最后提交，抛出异常则回滚，部署到用户的测试机器上验证，发现客户的服务器并没有回滚，前2条数据入库了；所以我们断定客户的环境出了问题。
11.后面一天我们都在修改was服务的配置，以为是数据源配置错了，导致数据库连接不受事务管理；折腾了一天之后，最后发现was环境下，即使外部开了事务，Connection的autoCommit状态就是true，不像tomcat，Connection受事务管理之后，autoCommit是false；
12.根据日志，如果说Connection的autoCommit状态是true是正确的，那么Connection的状态是false则可能就会存在问题；因为正确日志和错误日志只有这个地方存在区别；所以这个时候我们怀疑是连接坏了；继续分析日志，发现日志里面有在逻辑流里面调用了setAutoCommit的方法，用户代码将autoCommit属性设置了false，所以我们去走查用户代码，找到调用setAutoCommit的地方。
四.解决问题
1.找到用户代码之后，询问当事人为什么需要将Connection设置成false，当事人也说不出正确的理由，而且还说这个可以去掉，他只是复制的；所以我们将这行代码注释好之后，部署到测试服务器验证；同时验证打补丁之前和打补丁之后的测试环境，此时，则是环境能重现问题了，然后打上补丁之后，问题未能重现。第二天将补丁打到生产环境，问题也未能重现，问题即解决。
2.在问题的验证过程中，有人提出，在was容器下，Connection的autoCommit状态无论是true或者false对事务管理器没有任何影响，因为通过走j2ee事务的标准接口，在was容器下，无论autoCommit的状态是true还是false，事务管理器都是正常的；
3.第二天我们对这一问题进行了验证，发现在was环境下，通过j2ee事务的标准接口使用事务，Connection的autoCommit状态true或者false，标准接口的事务确实不受影响；所
以从另一个方面来说，eos的事务管理器对Connection的autoCommit状态为false这种情况支持的不够完善；
五.结论
1.从解决问题的角度，我们不建议用户直接将Connection的autoCommit设置为false，理由就是这样破坏了数据库连接；如果用户需要将连接设置为false，则需要在用完连接后，将连接的状态设置回去；或者直接在外层使用事务。
2.从产品的角度，由于标准接口true或者false2种情况都支持，所以也可以说是EOS的事务管理器支持的不完善，在特定的环境下，事务管理器应该支持这2种情况。
分享
EOS6中配置C3P0数据源自动重连方案
文章 > hanning > 文章详情
EOS6中配置C3P0数据源自动重连方案
hanning 发表于 9个月前 来自话题 #应用开发平台（EOS Platform）# ·
116 浏览
【适用范围】 EOS6.0、Tomcat、Jboss、Oracle
【问题描述和定位】在使用EOS6.0的时候，启动了Server后，如果网络出现问题Connection reset异常，Oracle数据库连接断了后就不能进行操作了，需要重新启动Server。那么，怎样配置可以避免重启Server，特别对于生产环境而言，需要尽可能的避免重启。
【解决方案和步骤】
1、Tomcat：在EOS Governor控制台的配置->数据源中，选中某数据源，点击修改，将“连接重试次数”默认值-1修改为1，点击“确定”保存。重启Server。 或者直接修改目录D:\\primetonfor3207_platform\\eosserver\\working\\eos-default\\config下user-config.xml文件中DataSource的配置：
2、JBoss：修改$JBOSS_HOME\\server\\default\\deploy下的EOSProductDataSource-ds.xml，将默认的数据源配置改成如下（与EOS5环境下配置类似）： OracleValidConnectionChecker 【备注】 修改这个配置还可以解决如果系统中需要多数据源的话，在这个文件中增加一个local-tx-datasource 配置； 上面的配置可能对系统访问数据库的性能有影响，有可能每次拿数据库连接的时候都会自动调用这个sql语句； Weblogic、Websphere等应用服务器也应该提供了类似的自动重连机制，可以进到它们的控制台查看。 EOS异常处理方法 异常获取