Workflow Project 目前状态
版本 0.11
已经完成
1。完成了接口1 和接口2 的方法
2。完成接口3的默认实现
3。完成事务回滚的实现方法－等待测试
未完成
1。接口3的注册与实例化解决方案
2。应用的并发访问问题以及解决数据的脏读问题
3。与具体的某个应用挂接并测试
－事务的回滚
OSWorkFlow的事务回滚是依靠WorkflowContext这个接口来实现的，在New出某个WorkFlow的时候需要声明WorkflowContext的实现类，一般会采用uper.context = new GearWheelWorkFlowContext(_caller);方法
比如这样实现：
public GearWheelWorkFlow(String _caller)
{
super.context = new GearWheelWorkFlowContext(_caller);
}
但OSWorkFlow的WorkflowContext的默认实现BasicWorkFlowContext中根本没有实现setRollbackOnly方法，也就没有了参考的可能
再看看这个接口的其他实现类也都是建立在JTA这样的跨Session的事务服务上，比如它的EJB的实现也是要调用容器提供的JTA实现才行！而JTA的实现比如要JNDI到数据库池，此时的应用光JTA+JNDI就已经宣布 －这样的例子必须生存在应用服务器的环境下！！
可是，我不死心，我记得Hibernate可以实现本地事务，也就是依靠JDBC本身的事务处理能力，而要实现这样的功能就需要在数据库连接的获取上下一些功夫，也就是要保证回滚的数据库连接必须是获取时的那个连接，而存储连接就成了一个需要首先解决的问题。
解决数据库连接的存储问题
目前存储数据库连接除了依靠静态类外，还有一个通用的方法ThreadLocal类，这样获取数据库连接的方法写成了如下的形式：
package com.company.common;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import org.apache.log4j.Logger;
public class DB2ConnectFactory
{
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(DB2ConnectFactory.class);
private static ThreadLocal threadLocal = new ThreadLocal();
//~
private Connection connect = null;
private Statement state = null;
private ResultSet result = null;
private boolean closeConnWhenDone = false;
//~
private String url = "jdbc:db2:WORKFLOW";
private String user = "";
private String password = "";
private String driverClassName = "COM.ibm.db2.jdbc.app.DB2Driver";
public DB2ConnectFactory() throws SQLException
{
this.init();
}
/**
* 获取数据库连接
* @return
* @throws SQLException
*/
public Connection getConn() throws SQLException
{
return (Connection)threadLocal.get();
}
/**
* 初始化数据库,并在缓冲中注册数据库连接
* @throws SQLException
*/
private void init() throws SQLException
{
try
{
// Get connect object
Class.forName(driverClassName);
closeConnWhenDone = true;
connect = DriverManager.getConnection(url, user, password);
state = connect.createStatement();
//Register the connection object in the threadlocal
threadLocal.set(connect);
}
catch (Exception e)
{
e.printStackTrace();
throw new SQLException(e.getMessage());
}
}
}
解决事务回滚
刚才说了需要实现WorkflowContext接口
package com.company.engine.workflow;
import java.sql.Connection;
import java.sql.SQLException;
import org.apache.log4j.Logger;
import com.company.common.DB2ConnectFactory;
import com.opensymphony.workflow.WorkflowContext;
public class GearWheelWorkFlowContext implements WorkflowContext
{
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(GearWheelWorkFlowContext.class);
private static ThreadLocal threadLocal = new ThreadLocal();
// ~ Instance fields
// ////////////////////////////////////////////////////////
private String caller;
// ~ Constructors
// ///////////////////////////////////////////////////////////
public GearWheelWorkFlowContext(String caller)
{
this.caller = caller;
}
// ~ Methods
// ////////////////////////////////////////////////////////////////
public String getCaller()
{
return this.caller;
}
/**
* Tranaction : Set Roll back
* @throws SQLException
*/
public void setRollbackOnly()
{
Connection connect = null;
try
{
DB2ConnectFactory factory = new DB2ConnectFactory();
connect = factory.getConn();
if(connect != null) connect.rollback();
}
catch (Exception e)
{
e.printStackTrace();
}
finally
{
this.clostConnection(connect);
}
}
private void clostConnection(Connection connect)
{
try
{
if(connect != null) connect.close();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
总结
1。我们可以看到由于接口中setRollbackOnly没有异常的声明，方法中即使抛出了异常也要自己"忍了"！看来良好的接口声明其实是非常重要的。
2。而且需要重载原来JDBCWorkflow 中的cleanup方法，将其中的代码屏蔽掉！数据库的关闭放在了setRollbackOnly访访的finally中，原因就是由于我们要统一的管理数据库连接所引发的，我们不能够在WorkFlowStore的每一个方法执行完毕后就关闭连接，因为这样的话你根本没有了事务回滚的可能，所以此时的连接需要在WorkflowContext中来处理。
感触
OSWorkFlow的实现方法并不是像网上所说的那样的优秀和文雅，更像是一个未完成任务的"半成品"，Heni被网上鼓吹为大牛，但一个不写注释和文档的人，根本称不上什么大牛！
OSWorkFlow更多的是实现了一个微内核，而它的用户模式是与OSUser这样的框架耦合的（偶已经将这样的耦合打开了，也就是接口3的定义），它的相关数据是与PropertySet框架耦合的（也就是接口2的定义），而且采用OSWorkFlow要经过很原始的修改（比如我实现了DB2下的WorkFlowStore的实现）。
不过也好即使以后不采用OSWorkFlow，自己实现一个这样的引擎也应该没有什么问题的，有时间了我倒是很想看看别的工作流的产品。
