JBPM+spring 排错经历

本文探讨了JBPM中任务执行结果未能正确持久化的问题。通过详细分析代码执行流程,作者发现持久化操作发生在特定条件下,并给出了一个临时解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

10个小时!被一个问题困扰!

问题描述:



用户执行一个任务的时候,JBPM没有把任务执行的结果持久化的数据库中。即没有任何的update或insert语句产生。而我所看的实例中,(实例没有spring),同样的代码却执行了持久化工作。通过观察流程的输出,已经可以看到成功的执行到了下一个流程节点,但是因为没有持久化,所以流程的信息没有被保存。



以下是java代码:
[quote]

jbpmTemplate.execute(new JbpmCallback(){



public Object doInJbpm(JbpmContext context) throws JbpmException {

TaskInstance instance = context.getTaskInstance(tid);

System.out.println("----------------"+instance.getName());

if("ok".equals(result))

{

instance.end();


}

if("no".equals(result))

{

instance.end("部门审批驳回");

}

return null;

}


});

[/quote]


因为使用了spring-jbpm-module,此处使用了它提供的jbpmTemplate



我开始跟踪源代码,在instance.end初设置断点。



TaskInstance类 执行end方法:核心代码:

if (transition==null) {

log.debug("completion of task '"+task.getName()+"' results in taking the default transition");

token.signal();

} else {

log.debug("completion of task '"+task.getName()+"' results in taking transition '"+transition+"'");

token.signal(transition);

}




然后进入Token类的signal方法

核心代码: node.leave(executionContext, transition);

进入Node类的leave方法:

核心代码:transition.take(executionContext);

进入Transition类的take方法:将执行环境传入方法中

核心代码:to.enter(executionContext);

再次进入Node类 这已经是下一个节点了。至此,已经完成了从一个节点进入另一个节点的过程调度。

没有发现任何的持久化代码!

究竟持久化代码在什么地方呐?

我突然想到,我使用的是JbpmTemplate类,调用它的doInJbpm方法,是一个回调方法,我于是又找到doInJbpm方法的源码:


public Object execute(final JbpmCallback callback) {

final JbpmContext context = getContext();



try {

// use the hibernateTemplate is present and if needed

if (hibernateTemplate != null && hasPersistenceService) {



// use hibernate template

return hibernateTemplate.execute(new HibernateCallback() {

/**

* @see org.springframework.orm.hibernate3.HibernateCallback#doInHibernate(org.hibernate.Session)

*/

public Object doInHibernate(Session session) throws HibernateException, SQLException {

// inject the session in the context

context.setSession(session);

return callback.doInJbpm(context);

}

});

}



// plain callback invocation (no template w/ persistence)

return callback.doInJbpm(context);



}

catch (JbpmException ex) {

throw convertJbpmException(ex);

}

finally {

releaseContext(context);

}



}


可以看到,它在执行完你实现的doInJbpm方法后在finally体中有个releaseContext方法,

从名字可以看出,该方法是释放jbpm上下文信息的。

看它的源码:

只有一句:jbpmContext.close();

再往里找:核心代码:


if (services!=null) {

try {

autoSave();

} finally {

services.close();

}

}




我看到了autoSave()方法。

我就开始找autoSave的源码:



if (autoSaveProcessInstances!=null) {

Iterator iter = autoSaveProcessInstances.iterator();

while (iter.hasNext()) {

ProcessInstance processInstance = (ProcessInstance) iter.next();

save(processInstance);

iter.remove();

}

}




我又执行了一次业务,发现执行到这儿的时候autoSaveProcessInstances是null,结果就没有执行下面的代码,整个执行也就结束了。

但是我在跟踪例子的时候发现它这儿的autoSaveProcessInstances也是null。

那是哪句呐?

又看了jbpmContext.close();源码:发现又有个finally块:

services.close();

继续找它的源码:

里面最核心的代码也只有一句: service.close();

service是个什么东东呐?是个接口,看它的实现:

通过断点跟踪,这儿的实现是:DbPersistenceService 这个也是我们在jbpm.cfg.xml中配置的。

看它对service.close的实现:



核心持久化代码:

Exception commitException = commit(); 这是在跟踪示例的时候发现是这一句完成的持久化工作。

从感觉上,似乎是异常后完成的事务提交...

而执行这一句的必要条件是:

if (! isRollbackOnly()) {....}

而我在跟踪我的代码的时候,发现这儿的if(...)内是false。。。这个isRollbackOnly是哪儿设置的呐?什么时候设置的 呐?我突然想起我对我的那个purchaseApplyService配置了spring的事务,于是我就去掉了事务配置。执行,结果还是一样。

我再次找了这个isRollbackOnly方法 。核心代码:return txService.isRollbackOnly();

这应该是个事务配置。但是在哪儿设置的rollbackOnly呐?我找到了TxService类。然后找到它的setRollbackOnly方法,使用eclipse找调用它的地方,发现:在JbpmContext类中有方法:


/**

* mark this transaction for rollback only in the persistence service.

* The {@link #close()} operation will then perform a rollback.

*/

public void setRollbackOnly() {

TxService txService = (services!=null ? services.getTxService() : null);

if (txService!=null) {

txService.setRollbackOnly();

} else {

throw new JbpmException("no transaction service configured");

}

}



于是我想,是不是我在使用springTemplate的方法时候,它给我提供的jbpmContext有问题呐?但是究竟是杂回事,我还是没有找到答案,但是找到个临时的解决办法,就是不使用jbpmContext,并且把JbpmConfiguration注入到我的PurchaseApplyFlowService类里。现在我的代码是:


JbpmContext jbpmContext=jbpmConfiguration.getCurrentJbpmContext();

if(jbpmContext==null)

{

jbpmContext=jbpmConfiguration.createJbpmContext();

}


TaskInstance ti=jbpmContext.getTaskInstance(Long.parseLong(taskId));

if("ok".equals(result))

{

ti.end();

}

if("no".equals(result))

{

ti.end("部门经理驳回");

}

jbpmContext.close();



执行,发现成功执行了持久化工作。。。
【基于QT的调色板】是一个使用Qt框架开发的色彩选择工具,类似于Windows操作系统中常见的颜色选取器。Qt是一个跨平台的应用程序开发框架,广泛应用于桌面、移动和嵌入式设备,支持C++和QML语言。这个调色板功能提供了横竖两种渐变模式,用户可以方便地选取所需的颜色值。 在Qt中,调色板(QPalette)是一个关键的类,用于管理应用程序的视觉样式。QPalette包含了一系列的颜色角色,如背景色、前景色、文本色、高亮色等,这些颜色可以根据用户的系统设置或应用程序的需求进行定制。通过自定义QPalette,开发者可以创建具有独特视觉风格的应用程序。 该调色板功能可能使用了QColorDialog,这是一个标准的Qt对话框,允许用户选择颜色。QColorDialog提供了一种简单的方式来获取用户的颜色选择,通常包括一个调色板界面,用户可以通过滑动或点击来选择RGB、HSV或其他色彩模型中的颜色。 横渐变取色可能通过QGradient实现,QGradient允许开发者创建线性或径向的色彩渐变。线性渐变(QLinearGradient)沿直线从一个点到另一个点过渡颜色,而径向渐变(QRadialGradient)则以圆心为中心向外扩散颜色。在调色板中,用户可能可以通过滑动条或鼠标拖动来改变渐变的位置,从而选取不同位置的颜色。 竖渐变取色则可能是通过调整QGradient的方向来实现的,将原本水平的渐变方向改为垂直。这种设计可以提供另一种方式来探索颜色空间,使得选取颜色更为直观和便捷。 在【colorpanelhsb】这个文件名中,我们可以推测这是与HSB(色相、饱和度、亮度)色彩模型相关的代码或资源。HSB模型是另一种常见且直观的颜色表示方式,与RGB或CMYK模型不同,它以人的感知为基础,更容易理解。在这个调色板中,用户可能可以通过调整H、S、B三个参数来选取所需的颜色。 基于QT的调色板是一个利用Qt框架和其提供的色彩管理工具,如QPalette、QColorDialog、QGradient等,构建的交互式颜色选择组件。它不仅提供了横竖渐变的色彩选取方式,还可能支持HSB色彩模型,使得用户在开发图形用户界面时能更加灵活和精准地控制色彩。
标题基于Spring Boot的二手物品交易网站系统研究AI更换标题第1章引言阐述基于Spring Boot开发二手物品交易网站的研究背景、意义、现状及本文方法与创新点。1.1研究背景与意义介绍二手物品交易的市场需求和Spring Boot技术的适用性。1.2国内外研究现状概述当前二手物品交易网站的发展现状和趋势。1.3论文方法与创新点说明本文采用的研究方法和在系统设计中的创新之处。第2章相关理论与技术介绍开发二手物品交易网站所涉及的相关理论和关键技术。2.1Spring Boot框架解释Spring Boot的核心概念和主要特性。2.2数据库技术讨论适用的数据库技术及其在系统中的角色。2.3前端技术阐述与后端配合的前端技术及其在系统中的应用。第3章系统需求分析详细分析二手物品交易网站系统的功能需求和性能需求。3.1功能需求列举系统应实现的主要功能模块。3.2性能需求明确系统应满足的性能指标和安全性要求。第4章系统设计与实现具体描述基于Spring Boot的二手物品交易网站系统的设计和实现过程。4.1系统架构设计给出系统的整体架构设计和各模块间的交互方式。4.2数据库设计详细阐述数据库的结构设计和数据操作流程。4.3界面设计与实现介绍系统的界面设计和用户交互的实现细节。第5章系统测试与优化说明对系统进行测试的方法和性能优化的措施。5.1测试方法与步骤测试环境的搭建、测试数据的准备及测试流程。5.2测试结果分析对测试结果进行详细分析,验证系统是否满足需求。5.3性能优化措施提出针对系统性能瓶颈的优化建议和实施方案。第6章结论与展望总结研究成果,并展望未来可能的研究方向和改进空间。6.1研究结论概括本文基于Spring Boot开发二手物品交易网站的主要发现和成果。6.2展望与改进讨论未来可能的系统改进方向和新的功能拓展。
1. 用户与权限管理模块 角色管理: 学生:查看个人住宿信息、提交报修申请、查看卫生检查结果、请假外出登记 宿管人员:分配宿舍床位、处理报修申请、记录卫生检查结果、登记晚归情况 管理员:维护楼栋与房间信息、管理用户账号、统计住宿数据、发布宿舍通知 用户操作: 登录认证:对接学校统一身份认证(模拟实现,用学号 / 工号作为账号),支持密码重置 信息管理:学生完善个人信息(院系、专业、联系电话),管理员维护所有用户信息 权限控制:不同角色仅可见对应功能(如学生无法修改床位分配信息) 2. 宿舍信息管理模块 楼栋与房间管理: 楼栋信息:名称(如 "1 号宿舍楼")、层数、性别限制(男 / 女 / 混合)、管理员(宿管) 房间信息:房间号(如 "101")、户型(4 人间 / 6 人间)、床位数量、已住人数、可用状态 设施信息:记录房间内设施(如空调、热水器、桌椅)的配置与完好状态 床位管理: 床位编号:为每个床位设置唯一编号(如 "101-1" 表示 101 房间 1 号床) 状态标记:标记床位为 "空闲 / 已分配 / 维修中",支持批量查询空闲床位 历史记录:保存床位的分配变更记录(如从学生 A 调换到学生 B 的时间与原因) 3. 住宿分配与调整模块 住宿分配: 新生分配:管理员导入新生名单后,宿管可按专业集中、性别匹配等规则批量分配床位 手动分配:针对转专业、复学学生,宿管手动指定空闲床位并记录分配时间 分配结果公示:学生登录后可查看自己的宿舍信息(楼栋、房间号、床位号、室友列表) 调整管理: 调宿申请:学生提交调宿原因(如室友矛盾、身体原因),选择意向宿舍(需有空位) 审批流程:宿管审核申请,通过后执行床位调换,更新双方住宿信息 换宿记录:保存调宿历史(申请人、原床位、新床位、审批人、时间) 4. 报修与安全管理模块 报修管理: 报修提交:学生选择宿舍、设施类型(如 "
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值