A few months ago, i had a problem in Persistence Store of JMS queues, soon after perform server restart, I get error from persistence store to recover message:
weblogic.store.PersistentStoreFatalException: [Store:280064]invalid handle 55981 (server="EVENTS01" store="JDBCStore_3022" table="JDBCStore_3022WLStore"),
To resolve this problem, just add this parameter on server startup arguments:
-Dweblogic.store.StoreBootOnError = true
With this parameter, the server starts with OK status in WebLogic 11g and with FAILED status in Weblogic 12c, but in both the processing of the messages continues when active,
to remove FAILED status in Weblogic 12c, just need to truncate persistence table in database and restart server (This solution can be found in Oracle Docs).
This solution did not solved my problem, because I can’t lost or delete messages.
Let’s go analyse the problem:
If I perform server start with paramenter mendioned above, I get this error:
weblogic.store.PersistentStoreFatalException: [Store:280064]invalid handle 55981...
If I perform server start without parameter, I get this errors:
BEA-280061 The store "JDBCStore_3022" could not be deployed: weblogic.store.io.jdbc.JDBCStoreException: [Store:280 065]open failed (server="EVENTS01" store="JDBCStore_3022" table="JDBCStore_3022WLStore"):(Linked Cause, "java.lang.Exception: java.lang.AssertionError") BEA-310006 - Critical subsystem PersistentStore.JDBCStore_3022 has failed. Setting server state to FAILED. Reason: weblogic.store.PersistentStoreFatalException: [Store:280064]invalid handle 55981 (server="EVENTS01" store="JDBCStore_3022" table="JDBCStore_3022WLStore")>
After analyse the two behaviors, and pay special attention to this error: (Ignoring 2PC record for sequence…). I went to invetigate what is the better configuration to use JMS with Global transactions, because I always a doubt of why Datasource of persistence is non-XA, what is behavior of global transactions in this case? And then, I found about LLR Optimization (Logging Last Resource).
The use of this configuration, explains why do can not uses Driver XA for JDBC persistence Store.
The information below can be found HERE.
About the LLR Optimization:
In many cases a global transaction becomes a two-phase commit (2PC) transaction because it involves a database operation (using JDBC) and another non-database operation, such as a message queueing operation (using JMS). In cases such as this where there is one database participant in a 2PC transaction, the Logging Last Resource (LLR) Optimization transaction option can significantly improve transaction performance by eliminating some of the XA overhead for database processing and by avoiding the use of JDBC XA drivers, which typically are less efficient than non-XA drivers. The LLR transaction option does not incur the same data risks as borne by the Emulate Two-Phase Commit JDBC data source option and the NonXAResource resource adapter (Connector) option.
LLR processing details
At server boot or data source deployment, LLR data sources load or create a table on the database from which the data source pools database connections. The table is created in the schema determined by the user specified to create database connections. If the database table cannot be created or loaded, then server boot will fail.
Within a global transaction, the first connection obtained from an LLR data source reserves an internal JDBC connection that is dedicated to the transaction. The internal JDBC connection is reserved on the specific server that is also the transactions’ coordinator. All subsequent transaction operations on any connections obtained from a same-named data source on any server are routed to this same single internal JDBC connection.
When an LLR transaction is committed, the WebLogic Server transaction manager handles the processing transparently. From an application perspective, the transaction semantics remain the same, but from an internal perspective, the transaction is handled differently than standard XA transactions. When the application commits the global transaction, the WebLogic Server transaction manager atomically commits the local transaction on the LLR connection before committing transaction work on any other transaction participants. For a two-phase commit transaction, the transaction manager also writes a 2PC record on the database as part of the same local transaction. After the local transaction completes successfully, the transaction manager calls commit on all other global transaction participants. After all other transaction participants complete the commit phase, the related LLR 2PC transaction record is freed for deletion. The transaction manager will lazily delete the transaction record after a short interval or with another local transaction.
If the application rolls back the global transaction or the transaction times out, the transaction manager rolls back the work in the local transaction and does not store a 2PC record in the database.
Firt Step:
Create a Datasouce to persistence Store with Non-XA Driver.
Second Step:
Go to the transaction page of the new Datasource, and select these check boxes as below:
Restart the server and hope to never lose messages in persistence again!
Dieison.
In Weblogic documentation:
Handling JMS Transactions with JDBC Stores
The JDBC store must use a JDBC data source that uses a non-XA JDBC driver and has Supports Global Transactions disabled. This limitation does not remove the XA capabilities of layered subsystems that use JDBC stores. For example, WebLogic JMS is fully XA-capable regardless of whether it uses a file store or any JDBC store.
Because the JDBC store implements the XAResource interface, it acts as it’s own resource manager and handles the transactions above the JDBC driver level. That is, the store itself implements the XAResource and handles the transactions without depending on the database (even when the messages are stored in the database).