现在作一个产品:新闻发布系统.
我想这个产品应该有很多人了解了,就不再详细说明了.
现在有个问题:事务.
在文档的采集过程中,用到了工作流,也就是说,文档的采集过程是一个流程.比如:采集-->编辑-->审批-->批注-->预发布-->发布.而工作流引擎是别的系统,可能是别的公司产品.
容易出错的地方:比如,我先插入一条数据到doc表中,接着调用workflow engine的接口(她可能也是插入一条记录),结果可能是:我这里成功,到工作流中出错了.下次查询无此记录,我这里的数据成了垃圾数据.
这两个系统如何实现事务处理比较好,比较容易!
充分利用J2EE的事务机制功能，如果将这些工作流逻辑放置在EJB层，效果会非常好，可惜实现技术复杂，对开发者素质要求比较高。
不知道怎么处理，Workflow是跨越长时间的，假设Workflow启动一个事务开始后，过两天才提交，行吗？估计不是锁死，就是提交失败。
两个系统接口总会出现这样的问题,完全保证事务很难也没必要措施.你必须找出为什么会出问题,错误原因是什么,尽量解决已知原因的错误,对于还没发现原因的错误必须有错误处理机制,不管是技术上还是业务上的.
我也有想过jta,但是觉得非常复杂,所以觉得有些彷徨.我觉得一个系统中两个接口也会出现类似的问题,因为两个接口无法共有同一个数据库连接,所以数据库的事务就无法使用.一直没有想到一个比较好的解决办法~~~
To banq :
workflow可能是别人的产品,无法控制别人用什么技术.再说,现在workflow都从ejb换到javabean了,因为这样workflow和外系统集成的时候就比较容易些,而且对外系统没有任何要求.
你的需求是把两种完全不同的接口混淆在一起：一种是数据库操作，提供事务接口，执行时间短；另一种是你的工作流，不提供事务接口（无法提供？），执行时间长无法确定（涉及到人的参与）。
事实上既然你的工作流不提供事务接口，也就无法通过事务处理来解决这个同步问题。
两个系统之间的同步不一定要通过事务进行，很多时候实际情况也不允许，比如完全是第三方系统。这种时候一般采用额外的“补偿操作”，比如说工作流如果失败就激活指定的“补偿操作”清除doc表中的相应数据。
针对你的情况我建议把数据库操作放在工作流操作之后，这样同步处理很更加简单。