After integration with WebSphere mq6, was 6 needs to send JMS messages to MQ in EJB (Session Bean and message Bean. The EJB itself is in the JTA transaction environment of the container, and JMS is also included in the transaction management by default. Therefore, you must select "xa support enabled" for the configuration of the connection factory. this attribute will enable JMS operations to support the two-phase commit protocol. Otherwise, the message sending operation may trigger exceptions similar to the following (log files are lost and the complete exception information cannot be listed ):
Resources that support only one stage cannot be used in the JTA environment.
After XA support is enabled, JMS operations will have strict transaction support. If a transaction fails, it will be recorded in the was/profiles/server1/tranlog of the server, depending on the was version and custom configuration, the path of the folder may change.
After was is restarted, it reads the transaction records under tranlog and tries to restore the suspended transaction. If the operation cannot properly create XA resources, the following warning will be given:
========================================================== ==============================================
[06-5-12 11: 25: 25: 516 CST] 00000014 xarecoverydat e wtrn0005w: The xaresource of the transaction participant cannot be re-created and the transaction recovery may not be completed correctly. Resource: j2cxaresourceinfo:
Cfname = JMS $ connectionfactory $ jmsmanagedconnection @195100581
Configprops = [deployed resource adapter properties]
Transactionresourceregistration java. Lang. String dynamic
Inactiveconnectionsupport java. Lang. boolean true
Mcfclassname java. Lang. String com. IBM. ejs. JMS. wsjmsmanagedqueueconnectionfactory
Mcfconnectorname java. Lang. String JMS $ connectionfactory
Mcfobjecttype java. Lang. Integer 4
Dd = [Resource adapter DD]
Managedconnectionfactory Class Name: COM. IBM. ejs. JMS. jmsmanagedqueuesessionfactory
Connection factory Interface Name: COM. IBM. ejs. JMS. jmsmanagedqueuesessionfactory
Transaction support: 2
Reauthentication support: false
Dsprops = {mret = 1, host = 172.16.0.116, pint = 5000, Chan = C1, CCS = 1381, qmgr = sobeymam, FIQ = 1, RINT = 5000, Port = 1414, UCP = 1, TRAN = 1}
Mcfprops = NULL
Mmp rops = NULL
Mbeanprops = NULL
Cmconfig = [Resource-ref settings]
Res-auth: 1 (Application)
Res-isolation-level: 0 (transaction_none)
Res-sharing-scope: false (unrecoverable able)
Loginconfigurationname: NULL
Loginconfigproperties: NULL
[Other attributes]
Res-resolution-control: 999 (undefined)
Iscmp1_x: false (not cmp1.x)
Isjms: true (JMS)
Recoveryclasspath = NULL
. Exception stack tracing follows: Java. Lang. nullpointerexception
At com. IBM. ejs. j2c. j2cxaresourcefactory. getxaresource (j2cxaresourcefactory. Java: 173)
At com. IBM. ws. transaction. JTA. xarecoverydata. Recover (xarecoverydata. Java: 518)
At com. IBM. ws. transaction. JTA. partnerlogtable. Recover (partnerlogtable. Java: 511)
At com. IBM. ws. transaction. JTA. recoverymanager. resync (recoverymanager. Java: 1784)
At com. IBM. ws. transaction. JTA. recoverymanager. Run (recoverymanager. Java: 2241)
========================================================== ==============================================
The recovery operation is executed once every minute, so a large number of identical warnings may be generated in the log. Although this does not affect the use, it is not good.
The solution is to delete the tranlog directory and restart was. Solve the problem.