Matthew, > Why would two transactions need the same TX enqueue? Is it because > they are attempting to update the same row locally (which I have been=20 > unable to prove or disprove yet)? Is it because they are=20 > both going after the same rows remotely? Is it a lack of available = > slots > in the rollback segments (ie, not enough rollback segments)? What kind of TX enqueue waits are you experiencing? TX-6 or TX-4? TX-6 enqueue waits would indicate that a transaction is trying to lock a row in X mode when that row is currently being locked by another transaction in an incompatible mode. (most surely another TX-6 lock) . This is an application issue more than a database issue. TX-4 is a complete different matter. I faced TX-4 problems twice. The first one was related to the lack of free ITL slots in a table (or index), I don't remember. And the second time the TX4 wait was caused when a session was trying to insert a key value (part of an unique index) in a table after another session had already inserted the same value but had not yet commited. The second session waited in a TX 4 enqueue wait until the first one commited/rollback its transaction. HTH. Regards Diego. ----- Original Message ----- From: "Adams, Matthew (GE Consumer & Industrial)" <MATT.ADAMS@xxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Thursday, May 27, 2004 7:11 AM Subject: TX locks > I'm having a WHOLE lot of fun trying to track down > the source of some ORA-2049 (timeout: distributed > transaction waiting for lock) in a purchased app=20 > called Matrix. I have a number of questions I'm hoping=20 > someone can answer. > > Now, according to Metalink, this occurs when a session is=20 > waiting on a TX enqueue that another session is holding AND > the waiting session is performing a distributed operation > via a DB link. > > Also, according to Metalink (in a different document), TX > enqueues are taken on particular slots in particular rollback > segments. > > > If a new connection does, as it's first statment, a read across > a DB link, is a TX enqueue aquired immediately on a local rollback=20 > segment (as I think it is?) > > Why would two transactions need the same TX enqueue? Is it because > they are attempting to update the same row locally (which I have been=20 > unable to prove or disprove yet)? Is it because they are=20 > both going after the same rows remotely? Is it a lack of available = > slots > in the rollback segments (ie, not enough rollback segments)? > > None of these scenerios seem very likely in this case, but I'm=20 > grasping at straws here. > > > ---- > Matt Adams - GE Appliances - matt.adams@xxxxxxxxxxx > Just once, I wish we would encounter an > alien menace that wasn't immune to bullets.=20 > - The Brigadier > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------