在集群部署的情况下，应用程序需要做出调整，主要集中在四个方面：对httpsession的处理、对缓存的处理、共享的文件系统、synchronized关键字的失效。

对httpsession的处理

对httpsession的处理最为重要，因为对WEB程序而言，httpsession无疑是最重要的全局资源，它需要被多个web服务器所共享。

无共享的集群架构（SNA），在这样的集群中，每个节点具备完全相同的功能，并且不需要知道其他节点存在与否。每个节点JVM进程不保持全局状态，才能够保证n个JVM节点的幂等性，那些所有涉及到全局状态的，必须放在JVM进程之外，例如用户ID可以使用cookie，session可以放入数据库（这并不是一个好的选择），文件可以放在共享存储系统中。

也就是说httpsession的信息需要被保存在JVM进程之外，例如分布式缓存、数据库。

这里是方案：

1、使用会话cookie保存web服务器产生的sessionid
   为什么是sessionid而不是userid，原因在于谁也不知道除去登录外其他人会在httpsession里干些什么

2、自定义SessionMap<String,Serializable>同步保存httpsession内的信息
   自定义SessionMap同步httpsession，在操作httpsession时不用改变调用接口，不用东张西望

3、使用分布式缓存memcached保存自定义SessionMap<String,Serializable>

4、会话胶粘
   未失败转发的情况下没必要在memcached和httpsession之间复制来复制去，眉来眼去

5、使用SnaFilter处理失败转发

6、使用HttpSessionListener实现SessionMap<String,Serializable>的过期
   利用容器session 机制的好处,httpsession过期的时候干掉memecached里的SessionMap

下面根据web请求的过程分情况讨论该方案：

A、登录

根据请求的url判断是否是登录请求

在线人数保存在memcached里

B、 正常请求

C、 失败转发

D、登出

根据请求的url判断是否是登出请求

E、HttpSession过期

不hack memcached，使用HttpSessionListener，sessionDestroyed事件时根据sessionid删除memcached里的sessionMap（如果存在）

关于在线人数的统计：在线人数存储在memcached里，将在线人数与sessionMap绑定，往memcached里增加sessionMap时在线人数+1，删除时-1.

项目情况：是一个大型公司的内部办公系统，该系统有两个和一般企业应用不太一样的特点：一是用户量非常多，人员数达到2W左右，另一个是采用分级管理的形式，各个分公司数据分开管理。

我们的定位：我们是作为业务平台的提供商参与这个项目的，我们提供底层的开发平台，系统集成商在此基础上进行二次开发。

在项目从开发到部署的过程中遇到了很多的问题，也反映出很多问题。

一、怎么回事，跑得比猫还慢
项目开发完毕后部署在Ibm aix 小型机上，32G内存，16个cpu。应用服务器采用的是weblogic9.2，数据库是oracle10.0.2。上线后发现系统运行的非常缓慢，甚 至比开发环境下的tomcat还要慢。于是开始排查原因，最开始是对SQL进行监控，优先考虑是数据库访问性能产生瓶颈。通过监控，发现很多业务需要执行 大量的SQL语句，查看客户编写的相关代码，发现在查询数据时循环执行了大量SQL。主要原因在于他们在代码中循环调用了我们相关API，一个最典型的例 子是通过用户ID查找用户NAME，他们在业务表格里没有保存用户name，而是在查询的时候通过用户ID查找用户name填充到页面，几乎每一个查询都 是n+1。
 
另外由于平台使用了hibernate，使得oo编程得非常爽快，导致开发人员完全忽略了相应的数据库操作所带来的压力。很多业务逻辑直接通过PO叠加完成，把一些可以通过很少SQL完成的逻辑全部分散放置到PO里，导致了大量PO的交互和SQL语句。

开始优化SQL，优化的同时增加大量业务缓存。但优化完毕后运行缓慢的现象依旧存在，性能有了一定的提升但是不是非常明显。继续优化，其中考虑过 多频繁访问的数据使用内存数据库的方式。但是优化过后在tomcat上效果明显，部署到生产环境就问题依旧。于是考虑weblogic的配置问题，作为开 发平台提供商，我们只是提供系统开发相关方面的支持，对于应用服务器和数据库服务器只是做基本的配置系统可运行即可。但是在这个问题上系统集成商咬定是我 们平台的问题不放，并且存在一个很严重的问题：他们使用的是盗版的weblogic，这样根本就没有相应的技术支持。

问题的解决：最后是找了一个BEA曾经的开发人员，问题实际非常的简单，现场部署的weblogic默认是运行在32位机器上，与64位机器存 在一定的不兼容。通过替换相应的jar包，问题得到了解决，主要是IO方面。替换完毕后，速度提升了进30% 。该开发人员说，如果没有lisence，根本就不会得到这些替换的jar包。

二、内存耗尽了
访问速度的问题解决了，系统的使用量很快上来，马上遇到新的问题：内存耗尽了。严重到几乎每天都要out of memory一次。这种问题在客户现场频繁出现。

本地测试，tomcat，sun jdk 通过Jprofiler监测内存使用情况。在并发访问门户的情况下，内存确实存在暴涨的情况，100并发，内存使用立刻上升了150m左右，继续并发 100，再增长150m。但是很快在抵达高峰时会有一次gc发生，内存使用稳定在200m，内存里大量char[]数组对象。疲劳测试，内存使用曲线并没 有出现逐渐上升泄露的情况。换weblogic和jrocket测试，gc发生的更加频繁，内存使用稳定。
 
但是现场依旧频繁当机，内存根本释放不了，一直逐渐增长，典型的内存泄露。对系统缓存、单态对象包括spring管理的对象、IO流进行了统一 排查，依旧没有找到内存泄露的原因。使用IBM 工具分析heapdump文件，结果还是大量的char[]数组对象占据内存，查找应用，找不到相关业务对象引用。
 
问题解决：问题解决是一篇偶尔搜到的oracle论坛的帖子，这里http://forums.oracle.com/forums/message.jspa?messageID=1040570 。原因在于oracle10的数据库驱动对statement最后执行的结果集有着引用，并且不会释放，目的在于通过内存而换取更好的性能。数据库连接采 用的是weblogic的连接池，关于connection有个相关的statement cache设定，设定一个connection能够被缓存的statement个数，最大是1024，而现场就被设定为了1024！connection pool的connection个数被设置为了500 。真是个恐怖的设置。在将1024改为10后，内存使用量轰然倒地，稳定在1g左右。这个设置是在前面系统访问速度存在问题时由系统集成商的开发人员设置 上去的，他们将所有和优化相关的参数全部开到了最大。这个问题要是用户购买的是正版的weblogic和oracle的话，相信也会很快得到解决。

三、线程阻塞
内存泄露的问题解决后，线程阻塞的问题浮出水面。系统集成商报告是线程死锁，通过分析工具其实是线程阻塞，主要问题在于系统用到了 synchronized关键字，对工作流相关API全部使用了synchronized，原因在这里：http: //ronghao.javaeye.com/blog/205731 。分析发现一个工作项提交的操作在连接数据库时被挂起了20分钟！造成了大量线程的排队阻塞。被挂起的原因有很多种。我们采用的方法是将接口拆分和设置事 务timeout时间。但是这显然不是一个好方法。最后是去掉所有的synchronized关键字，将同步的问题交由数据库解决，问题解决。

四、反思
1、系统集成商为什么不购买正版？
2、开发平台提供商究竟在项目开发中处于一种什么样的位置？开发平台是否对所有软件开发问题都要负责？
3、开发平台是越封装越快乐吗？还是越封装越丑陋？

更具体的细节在这里：

 AIX+weblogic性能诊断记录

从事工作流以及相关开发已经三年。提到工作流，很多人都会想到BPM，想到业务流程。对于业务流程，我的理解经过了一个过程，从最开始对工作流抱有的不切实际的期望，到对BPM的一些看法，再到目前的趋于实际。有一些感触，也有一些理解。对于业务流程管理而言，我想说的是：BPM向左，工作流向右，都不靠谱，或者说它们实际所能描述的流程和这里的业务流程根本就风牛马不相及，不是一个概念，唯一的相同点是只不过都叫流程而已。

一、什么是业务流程

业务流程是一个技术术语，它具有准确的定义：有组织的活动，相互联系，为客户创造价值。

这句话很好理解。甚至可以说任何企业的活动都是以业务为主线，以流程为线索串联起来的。企业的规章制度、操作手册等都与业务流程有着契合点。

二、业务流程对于企业的意义

业务流程对于企业的意义不仅仅在于对企业关键业务的一种描述，更在于对企业的业务运营有着指导意义，这种意义体现在对资源的优化、对企业组织机构的优化以及对管理制度的一系列改变。这种优化的目的实际也是企业所追求的目标：降低企业的运营成本，提高对市场需求的响应速度，争取企业利润的最大化。

三、业务流程也是一个体系

业务流程通常的表现形式是流程图（不是唯一形式），毕竟图形是最易于理解的一种形式，但似乎我们太关注于流程图本身而忽略了其他。除了流程图之外，业务流程还应该包括目标和指导方针，这才是一个完整的业务流程。在梳理业务使用业务流程描述时首先要想到的是该流程所要达到的目标，能为客户创造什么价值，脱离开业务目标或者说纯粹为描述业务而描述业务是没有意义的。同时在制定业务流程时也要考虑到该业务流程的指导方针，同一个业务可能有很多种业务流程的描述形式，具体哪一种是最合适的，这里就必须有一个指导方针来进行约束。

四、业务流程的特征

1、层次性、逐层抽象

业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。

这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。

业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。不同层级的部门有着对业务流程不同的分级管理权限。决策层、管理者、使用者可以清晰的查看到下属和下属部门的业务流程。

为使得所建立的业务流程能够更顺畅的运行，业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

2、以人为本

组织中最重要的部分是人员的工作方式以及构成他们每日操作的工作流程。

人是业务流程的驱动者，组织中的每一个人都会在业务流程中充当一个角色。通过良好的业务流程，每一个人都会有自己清晰的职责，要求具有良好的沟通协作意识和团队意识，明确自己在一个个业务流程中所担当的角色。

同时对于参与其中的业务流程，每个人员都要有自己的反馈。

首先，每个人员都能查看到这些业务流程，他们需要充分理解这些业务流程、流程的业务意义和目的，这些业务流程通过切合他们理解能力的方式（切合业务的图形、说明文字、相应的制度、规范、标准等等）得以展现。

其次，对于流程运行中存在的问题或瓶颈，每个人员都要积极反馈（提出修改的建议，或者在权限范围内直接修改）以促进流程的持续改进，业务流程的管理和变动不仅仅是业务分析人员或管理人员的职责，每一个员工都要参与其中，否则只有失败。管理人员和决策层更重要的职责是制定出业务流程的规则和约束，在这个规则和约束范围内，员工可以根据变化的商业环境对业务流程做出迅速修改，这样不必等到领导了解情况后再做出决策从而失去机会。

3、对流程运行效益的分析

从企业投资者的角度来讲，好的业务流程设计必然是能够为企业带来最高利润的设计。因此，对业务流程的效益分析是评价业务流程的一个重要方面。财务数据是最关键的数据，但这种分析不一定完全是由数据支撑的，有些是不能量化的，比如人员效率等等。

五、业务流程管理

良好的业务流程管理是保证企业灵活运营的关键（业务流程管理又何尝不是一种业务流程？）。

1、业务分析

实际这也是业务流程管理最重要的部分。它需要对企业业务有着强大的分析能力，因为业务分析对企业的运营有着重大的指导意义，只有具备了这样的业务分析能力，才能把握住企业运转的真实流程，而且这种分析能力往往带有对整个行业的深刻理解和前瞻性。没有异议，业务分析在于人，与IT无关。

2、业务流程的持续改进

不仅仅是流程管理人员（管理决策层）根据运行效益的分析和商业环境的分析对流程进行重整。还包括每个员工对其参与的流程的持续反馈和持续改进。柔性的业务流程。

3、IT系统与业务流程的关系

IT系统与业务流程并没有直接的关系。正如06z在SOA帖子里表达的：soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。在落实到技术层面，你觉得一个soa产品究竟应该包括些什么内容呢？这些内容又能有多少是能够辅助大家对业务流程进行分析和测试，对业务元素进行重整和再分配？如果你们真的有这个能力，你们觉得是在这里继续开发软件过苦日子，还是去开拓商业咨询呢？我的观点是：SOA很美好，但是一落地就变成了小丑。所谓的业务流程管理软件同理。

可以这样理解：业务流程管理是一个很大的命题，IT系统通过信息化对它的子集进行支撑，这里的IT系统包括的范围很广泛，包括了所有的企业应用软件（所有的企业应用软件都可以看作是对企业某部分的业务流程进行的描述）。业务流程管理的核心在于业务流程的分析解构和重整，这点是所有软件都不可企及的，关键在于人。至于BPM还是工作流，它们本来就有它们自己的适用范围，硬要把它提升到业务流程管理的高度来宣传，那就真的和小丑一样，滑稽而可笑。

关注下篇：BPM是干什么的

用js编写自己的组件，测试一直是个头疼的问题。最开始大量使用alert，firebug出现后天突然蓝了。但人的欲望总是没有止境的，在面对越来越多的后台数据交互以及特定于不同业务数据不同的展现形式时，仿佛一夜回到解放前。

说说我现在的困境：

目前要做的是工作流的提交页面，也就是对当前办理工作的用户展现后续任务，根据不同的情况由用户选择或是引擎自动计算。这是最简单的情况，后续包括参与者的选择计算、时间服务设定以及Comment等等。
现在根据业务逻辑分为了四种情况：
1、串行
2、分支选择
3、M选N选择
4、复杂的分支组合
四种情况需要准备不同的业务测试数据，同时页面展现也是不同的。我采用的方式如下图：


针对每种情况都建立相应的测试文件夹，在各自文件夹下准备各自的业务测试数据以及测试页面。并且一个testcase往往需要很多的业务测试数据（和通用组件还是不太一样）。清晰还是清晰，但是问题在于这种测试还是人肉，做不到自动化测试，同时为了业务数据能够顺利插入不得不hack一些代码。当增加或改动部分代码后就要人肉返测一次，预计代码还会大量膨胀，相应的测试文件还会增加。真是苦海无边，无心睡眠。想想cc和junit真是幸福的像花一样。

我佛慈悲，不知道大家有什么好的方法没有？

收回

收回是工作流参与者对自己“已办任务”（对已完成的工作项）的一种操作，即参与者主动对已办理过的工作项进行重新办理。

为什么要收回？

参与者完成任务后，发现自己办理有错误等情况后，需要将此任务收回重新办理。

工作项的参与方式

目前有四种方式：共同参与、竞争参与、顺序参与、基于角色的共同参与。

下面会针对这四种方式进行讨论。

工作项收回模式

1、未触发下一节点的工作项的收回

即当前任务节点并未完成，依旧处于执行状态

1.1共同参与

如图：在节点A未结束之前，workitem1、workitem2和workitem3正常完成后可以任意收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.2顺序参与

如图：workitem1、workitem2和workitem3顺序完成，workitem1在workitem2签收（包括挂起和手工终止）前可以收回，同样，workitem2在workitem3签收（包括挂起和手工终止）前也可以收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.3竞争参与

因为只会产生一个workitem，该workitem完成后会立刻触发下一节点，所以不存在未触发下一节点的收回情况。

1.4基于角色的共同参与

与1.1相同。

2、已触发下一节点的工作项的收回

 

2.1共同参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3都可以执行收回操作。第一个工作项的收回将会导致节点B实例的删除，同时节点A重新恢复执行状态。

问题2：节点B处于什么状态节点A的工作项可以执行收回操作？

由A触发的节点B处于正在执行的状态，节点B所产生的工作项：

a共同参与   工作项均未签收、挂起或手工终止

b顺序参与    第一个工作项未签收、挂起或手工终止

c 竞争参与   工作项均未签收、挂起或手工终止

d角色        同共同参与

问题3：工作项收回产生的影响？

节点A重新执行，收回的工作项重新执行。节点B重新恢复未触发状态，B所产生的工作项全部删除。

2.2顺序参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3根据顺序可以依次执行收回操作。

2.3竞争参与

情况简单，只有一个工作项，所以可以直接收回。

2.4基于角色的共同参与

同2.1

工作流收回模式

后续触发节点只能是人工节点（可以是多个，至少一个），否则不支持收回。目前不支持父子流程之间的收回。

一个典型的同步汇聚情况：

节点1首先执行完毕，但是因为是同步汇聚，所以它不会触发实际的流转；而节点2的完成则会触发节点3的执行。在这种情况下，节点2的工作项可以执行收回操作，而节点1的工作项因为后续没有触发节点而不能收回。