Re: Oracle 7 Locking Tables

ORA-02049: timeout: *distributed* transaction waiting for lock So you are using multiple databases! That's a completely different story, as Oracle will not easily give up on the remote databse. There is an init.ora parameter distributed_lock_timeout, which determines how long Oracle waits for the remote database to obtain the lock. Probably you can reset that to 0, but I suppose there's always 'some' delay, so I'm not sure whether I can recommend doing that.

Hth,

Sybrand Bakker, Oracle DBA

owcoin <swingandamiss_at_americonline.com> schreef in berichtnieuws sio5e67to153_at_corp.supernews.com...
> Ah. Therein lies the rub. Here's the statement clients A and B are
 using:
>
> lock table mytable_t in exclusive mode nowait;
>
> Both clients execute this statement at the beginning of their processing
> with the intention that it will fail if another client is currently
> processing. What we've found instead is that if client A gets the lock
 and
> runs ahead, client B eventually generates this message:
>
> ORA-02049: timeout: distributed transaction waiting for lock
>
> what I'm wondering is why there is a timeout error if I'm using nowait?
> Shouldn't nowait return with an error immediately?
>
> owcoin
>
>
> Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote in message
> news:959144692.13161.0.pluto.d4ee154e_at_news.demon.nl...
> > There is *no* parameter.
> > Your only option is to use either explicit lock table ... nowait
> > or select for update nowait.
> >
> > Hth,
> >
> > Sybrand Bakker, Oracle DBA
> >
> > owcoin <swingandamiss_at_americonline.com> schreef in berichtnieuws
> > sim4l5mto1172_at_corp.supernews.com...
> > > (Oracle 7.3.4.4)
> > >
> > > I have multiple Java application clients that need to lock tables on
 the
> > > server while they are manipulating them. This is a lengthy process
 and
 the
> > > problem I have encountered is that while client A is performing its
 actions,
> > > client B attempts to grab the lock and begins its work. The fact that
> > > client A has the lock doesn't get passed back to B for a rather
 significant
> > > amount of time--and in the meantime client B gets neck deep in its own
 work.
> > > The delay is long enough that I suspect I have missed an Oracle
 parameter
> > > somewhere that would "lock failed" msg return more quickly. Does
 anyone
> > > know of any such parameter? Can anyone explain why an attempt to get
 a
 lock
> > > on several tables that are already locked doesn't return quickly?
> > >
> > > Thanks,
> > >
> > > Tim
> > >
> > >
> >
> >
>
>
Received on Wed May 24 2000 - 00:00:00 CDT