Author |
Message
|
veeru_hyd |
Posted: Wed Dec 29, 2010 5:39 am Post subject: CHARACTER:Transaction will be committed problem |
|
|
Novice
Joined: 28 Oct 2010 Posts: 23
|
Hi,
--- Same insertQuery Repost(Retry) <-- -- > out (Delay)<---
MQInput --Construct query--Compute(If any DB failure(Commit))--- out
Compute(If any DB failure(Commit)): Is executing the insert query. If there is any DBFailure.
out (Delay) : this will stop for few seconds.
Repost(Retry): this compute node will try to repost the same query again.
While reposting the message i am getting 'CHARACTER:Transaction will be committed, but a pending automatic transaction exists' error.
Could please suggest me what might be the problem.
--MV |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 29, 2010 5:48 am Post subject: Re: CHARACTER:Transaction will be committed problem |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
veeru_hyd wrote: |
Could please suggest me what might be the problem.
|
Something's wrong with the rollback after the 1st failure & the UOW is hanging/open. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
veeru_hyd |
Posted: Wed Dec 29, 2010 6:31 am Post subject: |
|
|
Novice
Joined: 28 Oct 2010 Posts: 23
|
Sorry, I did not get you. Can you explain me more detailed.
1. Compute(If any DB failure(Commit)) compute node:
I am checking
IF SQLSTATECODE =0 THEN
Proceed
ELSE
Propagate to terminal 'out1'.
2. Out1 --- Retry compute node: this compute node wait for few seconds and repost the message.
3. Retry compute--- Compute(If any DB failure(Commit)) compute node
-- I am not treating this as a Data base error by uncheck the Throw exception on data base error.
3. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 29, 2010 6:40 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
veeru_hyd wrote: |
Sorry, I did not get you. Can you explain me more detailed. |
I would assume (because you've not said) that the entire flow is in the same unit of work. When you get a non-zero code from the 1st db action you then try it again in the same flow & hence the same unit of work. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
veeru_hyd |
Posted: Wed Dec 29, 2010 7:27 am Post subject: that the entire flow is in the same unit of work |
|
|
Novice
Joined: 28 Oct 2010 Posts: 23
|
Yes, this entire flow is in same unit of work. Because first failure i am not treating this as failure and reprocessing the same query again to the the same flow and same compute node. Will it not allow?.
Before I have retried through failure terminal by extracting the DBException and i used to repost the in the same flow. That has not given any problem. The reason i am trying with the above approach. If DBOperation successfully done. If any failure occured in the down stream node, it is backing out and trying to process through this failure terminal due to PROPAGATE Statement.
--Veera |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 29, 2010 7:39 am Post subject: Re: that the entire flow is in the same unit of work |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
veeru_hyd wrote: |
Before I have retried through failure terminal by extracting the DBException and i used to repost the in the same flow. That has not given any problem. |
That's not the same as what you're doing here. If the message has been propagated through a failure terminal, WMB has rolled back to that point. Here you're moving forward through the flow. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|