-
15. Re: find out how many resources are enlisted in tx
Oh, BTW: I can confirm that <no-tx-datasource> resouces never get enlisted in transactions :) I watched my quartz jobs trigger relentlessly without ever causing 2PC to happen (and its quartz that uses the no-tx-datasource - my quartz jobs call SLSB methods that access the DB, so if the no-tx-datasource were to be enlisted, I would have seen 2PC since DB resources would also have been enlisted in the same tx, but that never happened).
-
16. Re: find out how many resources are enlisted in tx
Great. So are you done with this issue or are there still things remaining that need confirming?
-
17. Re: find out how many resources are enlisted in tx
Yes, I believe this is all done! In fact, since I believe I've now eliminated all possibilities of 2PC happening, I don't even think I need to confirm that my recovery object is working. Actually, I don't think I can - since I'm never writing tx logs to the object store, there will never be anything to recover in the first place.
However, all the work I did to switch over to XA and to get my recovery object implemented will remain in place just in case I need to introduce 2PC in the future.
Mark - if you did take the time (or plan to) to get that example for testing recovery, let me know - I'd still like to test it myself. Just let me know if you have anything that you think I'd be able to use and I'll revert back to my old code that uses 2PC and I'll test with your example. -
18. Re: find out how many resources are enlisted in tx
Hi Mazz. The test is already checked in to the trunk (has been since this morning my time - look for LogMoveTest.java). You should read the failure recovery guide to see how to configure it (also in trunk). This test just confirms the fix and is stand-alone.
-
19. Re: find out how many resources are enlisted in tx
Hi mazz,
If you want to instrument the TS code in order to trace execution you can use my test scripting tool TOAST. It attaches rules to specific points in the code and tests/fires the rule when control reaches the trigger point. For example, if you want to see when 2phase commit gets executed you could use a script like the following
RULE trace execute phase2commit
CLASS BasicAction
METHOD phase2Commit(boolean)
AT ENTRY
BIND NOTHING
IF TRUE
DO debug("executing phase2Commit for action " + $0)
ENDRULE
This will print the trace message when your code executes phase2Commit. You should see something along the lines of the following written to stdout:
12:17:46,166 INFO [STDOUT] rule.debug{trace execute phase2commit} : executing phase2Commit for action BasicAction: 7f000001:c2f0:4958becf:80 status: ActionStatus.COMMITTING
phase2commit is called either during phase 2 of a normal 2 phase commit or during replay of a prepared transaction found in the log at restart. So, if it gets called then you are using 2PC.
You could attach a similar rule to BasicAction.onePhaseCommit to trace execution of one phase commits.
In order to enable the agent you need to supply arguments on the java command line when you start the AS which provide a handle on i) the TOAST rule agent jar and ii) the script file containing the rules . Details of how to do this are in the README and/or the manual provided with the TOAST sources. Look for them is in the TS repository in directory
workspace/adinn/orchestration
Also, consult the manual for how to add specify other Java expressions in the BIND, IF and DO parts of the rule and how to specify other locations for the rule trigger point than just AT ENTRY.
regards,
Andrew Dinn