有没有谁碰到Weblogic应用服务器集群将客户端的一个请求并发为两个请求来同时进行处理?绝对实践中的真实问题

dctor 2004-12-22 09:38:25
本人现在公司用Java进行电子缴款系统模块的开发,
使用的是无状态SessionBean,
应用服务器为Weblogic配置的一个集群,
偶尔出现过1-2次并发操作(并发程度在1秒以内);
简单的说,我从前台发起一个扣款请求,从程序流程和EJB的架构来说,后台也应该发起一笔扣款请求;
问题就在于后台不只发起一起扣款请求,而是几乎同时发起两笔扣款请求,从而导致并发重复扣款;

暂时还没有找到具体产生原因,初步分析原因有两个
1)服务器集群算法出现Bug,导致同时有两个Bean在服务器中运作;
2)前台的事件处理存在Bug,同时发起了两个请求,只是界面上看不出来而已;

我的同事上次就这个问题发过问题,那是2个月前出现的一批并发重扣;
我今天再次发出此贴,就是因为前几天我又发现了一批并发重扣;

我们再上一次的教训上,这次多输出了一些调试信息,主要是Weblogic的事务信息如下:
连续两个我认为并发的Bean输出的日志如下(但是我不清楚这些日志代表什么意思):

2004-12-14 11:29:50,402 [system:124] [ExecuteThread: '8' for queue: 'weblogic.kernel.Default'] - ZScomm ZSetskkService.logTx jklsh = 3200412052036014
**********
txid1 = BEA1-72E10BBC0AA811840C29
**********
txid2 = BEA1-72E10BBC0AA811840C29
**********
TxStatus1 = Active
**********
TxStatus2 = Active
**********
timeSinceBegin1 = 645
**********
timeSinceBegin2 = 645
**********
tx1 = Name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)],Xid=BEA1-72E10BBC0AA811840C29(17975654),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=599,activeThread=Thread[ExecuteThread: '8' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190cb2a),SCInfo[coredomain+coreapp4]=(state=active),SCInfo[eaidomain+eaiserver]=(state=active),properties=({weblogic.transaction.name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)], weblogic.jdbc=t3://150.18.30.31:7013}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+)
**********
tx2 = Name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)],Xid=BEA1-72E10BBC0AA811840C29(17975654),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=599,activeThread=Thread[ExecuteThread: '8' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190cb2a),SCInfo[coredomain+coreapp4]=(state=active),SCInfo[eaidomain+eaiserver]=(state=active),properties=({weblogic.transaction.name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)], weblogic.jdbc=t3://150.18.30.31:7013}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+)

========================================================================================

2004-12-14 11:29:50,993 [system:124] [ExecuteThread: '20' for queue: 'weblogic.kernel.Default'] - ZScomm ZSetskkService.logTx jklsh = 3200412052036016
**********
txid1 = BEA1-72E50BBC0AA811840C29
**********
txid2 = BEA1-72E50BBC0AA811840C29
**********
TxStatus1 = Active
**********
TxStatus2 = Active
**********
timeSinceBegin1 = 763
**********
timeSinceBegin2 = 763
**********
tx1 = Name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)],Xid=BEA1-72E50BBC0AA811840C29(18172396),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=600,activeThread=Thread[ExecuteThread: '20' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@a82896),SCInfo[coredomain+coreapp4]=(state=active),SCInfo[eaidomain+eaiserver]=(state=active),properties=({weblogic.transaction.name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)], weblogic.jdbc=t3://150.18.30.31:7013}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+)
**********
tx2 = Name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)],Xid=BEA1-72E50BBC0AA811840C29(18172396),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=600,activeThread=Thread[ExecuteThread: '20' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@a82896),SCInfo[coredomain+coreapp4]=(state=active),SCInfo[eaidomain+eaiserver]=(state=active),properties=({weblogic.transaction.name=[EJB gov.gdlt.taxcore.gateway.facade.TaxFacadeGateWayBean.invokeTask(gov.gdlt.taxcore.comm.event.RequestEvent)], weblogic.jdbc=t3://150.18.30.31:7013}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=coreapp4+150.18.30.31:7013+coredomain+t3+)


...全文
205 6 打赏 收藏 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
dctor 2005-01-20
  • 打赏
  • 举报
回复
经过对前台日志的分析,
确定属于前台同时发起了两个请求,
只是适用了多线程技术,有个线程在后台运行看不出来而已
多谢各位的建议
GJA106 2005-01-14
  • 打赏
  • 举报
回复
这种问题比较麻烦。weblogic应该不会存在这种漏洞。
支持Lintops(披星戴月) 的看法,检查一下前台应用。存在不行,只能咨询weblogic专家了。
runer 2005-01-06
  • 打赏
  • 举报
回复
你说的这种情形是偶尔出现,还是一直如此?

估计程序的问题可能性大

1.检查一下前台到底发送了几个请求
2.检查Bean到底收到了几个请求
披星戴月 2005-01-04
  • 打赏
  • 举报
回复
2)前台的事件处理存在Bug,同时发起了两个请求,只是界面上看不出来而已;

个人觉得这个可能性比较大,可以通过weblogic端来监控一下一次操作客户端发送至服务端的具体请求数!
myy 2004-12-25
  • 打赏
  • 举报
回复
太高深了,太菜不懂ing.

想问一下,这样比较关键的动作,为什么不用数据库的并发锁定机制呢?
dctor 2004-12-22
  • 打赏
  • 举报
回复
=======输出以上日志信息所用到的方法如下=================
weblogic.transaction.Transaction t1 = weblogic.transaction.TxHelper.
getTransaction();
String txid1 = "" + t1.getXid();
String txStatus1 = "" + t1.getStatusAsString();
long timeSinceBegin1 = t1.getMillisSinceBegin();

weblogic.transaction.Transaction t2 = ((weblogic.transaction.
Transaction) weblogic.transaction.TransactionHelper.
getTransactionHelper().getTransaction());
String txid2 = "" + t2.getXid();
String txStatus2 = "" + t2.getStatusAsString();
long timeSinceBegin2 = t2.getMillisSinceBegin();

LogWritter.sysError("ZScomm ZSetskkService.logTx jklsh = " + jklsh +
" \r\n**********\r\n txid1 = " + txid1 +
" \r\n**********\r\n txid2 = " + txid2 +
" \r\n**********\r\n TxStatus1 = " + txStatus1 +
" \r\n**********\r\n TxStatus2 = " + txStatus2 +
" \r\n**********\r\n timeSinceBegin1 = " +
timeSinceBegin1 +
" \r\n**********\r\n timeSinceBegin2 = " +
timeSinceBegin2 +
" \r\n**********\r\n tx1 = " + t1.toString() +
" \r\n**********\r\n tx2 = " + t2.toString());
内容概要:本文针对质子交换膜燃料电池(PEMFC)在动态压力工况下的最大功率点跟踪(MPPT)问题,提出了一种压力工况协同调控下的自适应高阶滑模控制策略,并基于Simulink平台完成了系统建模与仿真实现。该策略融合高阶滑模控制的强鲁棒性与自适应机制的参数在线优化能力,有效克服了PEMFC系统固有的非线性、外部扰动及工况时变性等挑战,实现了对最大功率点的快速、精确与稳定跟踪。研究内容涵盖控制策略的理论设计、李雅普诺夫稳定性分析、自适应律构建以及在多种动态工况下的仿真实验验证,结果表明该方法相较于传统控制策略具有更快的动态响应速度、更小的稳态振荡以及更强的抗干扰能力,显著提升了PEMFC系统的能量转换效率与运行稳定性。; 适合人群:具备一定控制理论基础和Simulink仿真经验,从事新能源发电系统、燃料电池控制、电力电子变换或先进控制算法研究的研发人员及高校研究生。; 使用场景及目标:①应用于燃料电池发电系统的高性能最大功率点跟踪控制设计;②为解决强非线性、多扰动耦合的能源系统提供先进的自适应鲁棒控制方案;③通过Simulink仿真验证高阶滑模与自适应控制算法的有效性,服务于科研项目攻关或工程原型开发。; 阅读建议:建议读者结合Simulink模型同步学习,重点关注控制律设计原理、自适应机制实现方式及仿真结果对比分析部分,并可通过与传统滑模控制进行对比,深入理解该策略在鲁棒性与动态性能上的优越性。
下拉可见数据集可视化效果示意。 【数据集概况】 · 检测类别(中文):[滴落物(Drop)] · 训练集:2021 张 · 验证集:128 张 · 测试集:42 张 · 总计:2191 张 该数据集聚焦于工业生产环境中地面或设备表面出现的各类滴落物检测,通过多角度、多光照条件下的图像采集,全面覆盖了不同形态、颜色和材质的滴落物样本。数据集真实还原了车间地面、金属板、木质结构等复杂背景下的实际场景,为自动化巡检系统提供了高价值的视觉依据,有助于实现对潜在污染源或泄漏点的早期识别与预警。... 【训练曲线与评估图】 【模型训练配置】 参数 | 值 模型 | yolo26n 训练轮数 | 100 epochs 输入尺寸 | 640x640 批次大小 | 24 优化器 | auto 初始学习率 | 0.01 训练设备 【关键指标汇总】 训练了 71 个 epoch,最终轮指标: 指标 | 数值 mAP50 | **0.8949** mAP50-95 | 0.5139 Precision | 0.8991 Recall | 0.8527 train/box_loss | 0.8544 train/cls_loss | 0.4842 val/box_loss | 1.5612 val/cls_loss | 0.6862 【训练过程分析】 71 轮训练后 mAP50 为 0.8949,模型基本收敛但还有提升余地。Loss 曲线下降正常,后期趋于平缓。mAP50-95 为 0.5139,和 mAP50 差距 0.38,定位精度是主要短板。 【模型性能评估】 Precision 0.8991、Recall 0.8527,精度高于召回,存在一定漏检。 【预测效果展示】 验证集预测效果较好,检测框基本准确覆盖滴落物,置信度整体偏高。 【改进建议】 1. 增强难例挖掘:在大规模数据中筛选误检...

1,237

社区成员

发帖
与我相关
我的任务
社区描述
企业软件 中间件技术
社区管理员
  • 中间件
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧