一个 BC4J 的问题
这篇博客先写在这里, 等我解决了这个bug 再来填坑.
问题出现在一个 OAF page 上面, 点页面上的一个按钮, 会跳转到另一个页面, 这时会插入一条记录到表 A. insert 语句会自动给这条记录加上锁, 用下面的语句可以查到锁: select * from V$LOCKED_OBJECT where OBJECT_ID = 40873;
可是等了一会儿, 这条锁的记录就没了! 凭空就没了, 没有commit, 没有rollback, 没有delete, 反正锁就是丢了.
这个bug 已经跟了很久了, 感觉应该不是我们的代码造成的问题. ATG team 埋下了好多坑给我们啊…
2015年3月20日
ATG 的一个开发跟我说可能是因为页面跳转, AM 不一致导致的. 我看了下, 有这个可能, 但是即使设置了相同的AM 也不行.
2015年3月23日
没有头绪.
2015年3月25日
怎么看都是ATG 的问题. 没有理由一条记录被锁上之后又丢了. 业务代码是不会干这种事情的. 明天开会又要被老大说了, 崩溃, 已经一个月了…
2015年4月9日
今天这个bug 终于给关了. 原因果然不是我们的业务代码, ATG 不知道改了什么导致了这个问题. 浪费我好多时间去跟踪. 唉…
2015年5月11日
有一个客户报了同样的问题, 我找到环境去重现, 然后给ATG 录了bug, 今天终于有了点进展. 花了整整一个礼拜的时间去跟踪这个问题.
* MMUHANNA maher.muhanna 05/09/15 07:50 am *
@ Product team,
@
@ The usage you are following with MtlLotNumberEO is not correct and doesnt
@ follow the bc4j guidelines. The insert below from the Developer Guide:
@
@ PL/SQL Entity Object Design and Development.
@ Insert.
@ Warning: Do not bypass the insert PL/SQL call within your insertRow() method
@ since BC4J doesn’t have any way to know that you didn’t actually perform the
@ insert, and might try to lock the row at some point since it expects it to
@ exist.
@ The above statement is exactly what you are violating in your code.
@ Inserting a row via your pl/sql package and avoiding the direct call via your
@ EO.insertRow, is causing the issues you are running into.
我们的EO 确实是PL/SQL EO, 开发文档里面写了一段:
You should use the PL/SQL EOs only if you have legacy PL/SQL code that maintains all your
transactions and validations. If you are a new product and/or do not have a lot of PL/SQL legacy
code, the OA Framework recommends the use of Java EOs over PL/SQL EOs.
是说如果不需要重用大量PL/SQL 代码, 就不要用这种EO. 看起来确实是我们INV 的代码出的错. 要改的话会非常麻烦.
改了标题, 原本是”一个关于锁的问题”, 现在发现这不是锁的问题.
Related bugs:
20890307, 20970560, 20189648, 13637153, 17617332
Ref: InvLotDetailsAMImpl.java.oldlog
2015年5月14日
昨天晚上跟KD, 我们的老大, ATG 还有 DB 的开发一起讨论这个问题, 大家都还没有进展. 最新进展:
1. 可以重现的环境: me1yd224, mw2yd224, mo7yd224
2. 不能重现的环境: mw4yd225, ml3yu225
3. 配置好的Jdeveloper: /jdevbin/pf_122 launch /jdevbin/NT/1224_x9_17909318/ /rh2.1AS/nfs/src/fwkdev/bugs/bug20970560
4. 查询MLN 的锁: select * from V$LOCKED_OBJECT where OBJECT_ID = 40873;
5. 老大让我把 InvLotDetailsAMImpl.java revert to 120.21.12020000.6 and test on me1yd224;
2015年5月18日
最新进展:
在mw2yd224 上面可以重现这个问题, revert 了bug 17617332 的修改, 把下面两个问题改到
java/txnui/lotDetails/server/InvLotDetailsAMImpl.java 120.21.12020000.4
patch/115/sql/INVLTEOB.pls 120.4.12020000.3
到了这个版本之后, 在console 添加参数 “-Dweblogic.classloader.noJarSigners=true” 忽略JAR 包签名, 重启weblogic, 然后重现
点move out 之后, select * from v$locked_object where object_id in (40873); 发现这个记录在一段时间之后也会消失, 但是最后在finish 的时候没有再报原始的error.
诡异的bug.
2015年5月19日
现在的代码逻辑是, preprocessLot() 会在数据库插入一条MLN 记录, 里面有大量的逻辑, 会插入其他的字段.
如果我们用 insertRow() 在VO 里面插入一条记录, 可以让现在的界面不报错, 但是这么做很奇怪.
但是如果不用 insertRow(), 就会报错. ATG 说我们不遵守编码规范..
正常的逻辑应该用 preprocessLot() 插入数据库之后, 直接 findByKey() 查出来放入VO 就可以了.
本质上还是ATG 的问题, 只是他们不承认.
2015年5月20日
今天终于找到问题了.
wsm/mes/move/server/MoveTransactionsAM.xml 设置了 retention level = MANAGE_STATE, 去掉就可以了.
要研究下 retention level .