Re: Having Deadlock Problem

Hi andy,

"andy" <anandv81_at_rediffmail.com> wrote in message news:9bfbb3fd.0406080400.7b0419d5_at_posting.google.com...
>
> Thanks for your reply it was very helpful. You are right , COM+
> components intiate distributed transactions using XA interface
> provided by ORACLE. I have been analyzing this problem for a while now
> and had felt that this was a deadlock problem. What surprised me also
> was that there is no closed loop here .
> What happens is that the first transaction (session 13) gets stuck and
> holds the lock for indefinite period.
>
> The log file was generated by Oracle and the ORA 0249 error might not
> be the reason for this error.
>
> What I'm trying to figure out is why does the first transaction get
> stuck? Is there anyway I could locate this? or maybe atleast shortlist
> the possible causes why the first transaction getting stuck.
>
> Thanks in advance
>

 ORA-2049 happens when:

1. The session is waiting on a TX enqueue.
2. The transaction is distributed.
2. The session waits longer than distributed_lock_time (the default is 60

You can easily emulate this situation on a single db by creating a db link (loopback) pointing to the db itself and:

In Session 1:
1. select * from dual_at_loopback
2. update t1 set x=0 where pk=1;

In Session 2:
1. select * from dual_at_loopback
2. update t1 set x=0 where pk=1;

After 1 min, Session 2 will get an ora-2049 (the select from dual creates a distributed transaction context. Even though the updates are local, the transactions are treated as distributed).

Apparently, your 'first' session is holding the lock for more than 60 sec. without, say, committing. It may indeed be an application issue.

Also, there was a bug in MS MTS that created a situation similar to yours and the fix was to install MDAC 2.6 and NT SP6.

VC

> Andy
Received on Tue Jun 08 2004 - 09:48:53 CDT