Re: Transactions Getting IN-doubt
- From: Taral Desai <taral.desai@xxxxxxxxx>
- To: Abhijeet.Rajurkar@xxxxxxxxxx
- Date: Tue, 23 Feb 2010 23:46:15 -0600
You can try cleaning all using below. There was bug for this and setting
_smu_debug_mode might help. But test it first and then move forward.
select * from dba_2pc_pending;
rollback force <Values from column local_tran_id>;
commit;
alter system set "_smu_debug_mode"=4;
exec dbms_transaction.purge_lost_db_entry('Values from column
local_tran_id');
On Tue, Feb 23, 2010 at 11:27 PM, Abhijeet Rajurkar <
Abhijeet.Rajurkar@xxxxxxxxxx> wrote:
> Just to clarify, we are able to resolve the locks as and when they
> appear, ORAMTS service is configured and it’s doing the job perfectly, the
> issue remains is what is causing these locks intermittently.
>
> Are we missing some config setting of ODP.net or MSDTC or Connection Pool
> setting…. Any body who has worked with this combination of .Net application
> talking to Oracle DB with ODP.Net.
>
>
>
> Kind Regards
>
> Abhijeet
>
>
>
> *From:* Abhijeet Rajurkar
> *Sent:* 24 February 2010 10:29
> *To:* 'oracle-l@xxxxxxxxxxxxx'
> *Subject:* Transactions Getting IN-doubt
>
>
>
> We have a .NET 3.5 client application flowing transactions to transactional
> WCF Service.
>
> 1) Both the Client and WCF service applications (with TCP binding) perform
> database operations with Oracle 10.2.0.4 database using ODP.NET 11.
> 2) Both the client and WCF Service are installed on the same machine while
> Oracle database is on different server. Operation system: Windows Server
> 2003, Sp2
> 3) DTC service started on machine hosting client and WCF service.
>
>
>
> In the msdtc log it is observed that
>
> RM_COMMIT_DELIVERY_FAILED_DUE_TO_CONNECTION_DOWN which is causing the the
> transaction to go in-doubt state.
>
> There is no network failure. checked with NETMON. What can be the possible
> reasons.
>
> * *
>
> *The alert log shows*
>
> * *
>
> Mon Feb 22 16:49:00 2010
>
> DISTRIB TRAN 44444444.C60C554541BFE049871F76A5BBE95E6F00000000
>
> is local tran 4.8.5710 (hex=04.08.164e)
>
> insert pending prepared tran, scn=7494059 (hex=0.007259ab)
>
>
>
> An SR with oracle support did not help much any pointers/ clues will be
> helpful.
>
> * *
>
> *Regards,*
>
> *Abhijeet*
>
>
>
>
>
> MASTEK LTD.
> Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List.
> In the US, we're called MAJESCOMASTEK
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Opinions expressed in this e-mail are those of the individual and not that of
> Mastek Limited, unless specifically indicated to that effect. Mastek Limited
> does not accept any responsibility or liability for it. This e-mail and
> attachments (if any) transmitted with it are confidential and/or privileged
> and solely for the use of the intended person or entity to which it is
> addressed. Any review, re-transmission, dissemination or other use of or
> taking of any action in reliance upon this information by persons or entities
> other than the intended recipient is prohibited. This e-mail and its
> attachments have been scanned for the presence of computer viruses. It is the
> responsibility of the recipient to run the virus check on e-mails and
> attachments before opening them. If you have received this e-mail in error,
> kindly delete this e-mail from desktop and server.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
--
Thanks & Regards,
Taral Desai
Other related posts:
