Hi Shyam, You can synchronise the whole transaction with the 2 updates.That will take care of 1 of the issues.The other issue might be cyclic i.e are you updating table C first and then updating table A or B somewhere in your application.You will then have to make the updates in the same order i.e always update A first before C.This issue is a wild guess of mine-so I might be way off base here depending on row level locking etc.
Vijay -----Original Message----- From: Shyam A [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 6:36 PM To: Struts Users Mailing List Subject: Re: [OT] Database locking and deadlock Vic, Yes, I do get a "deadly embrace" or deadlock, as the row locks on the table multiply when they occur, holding up connections in the connection pool, eventually consuming all connections, and then all hell breaks loose. Were you referring to synchronizing with semaphores? I read somewhere that the Oracle database is supposed to handle deadlocks by rolling back one of the affected transactions. But the row locks seem to occur intermittently, possibly when there are large numbers of concurrent users. I cannot avoid the transaction as the database updates have to be done as one unit. An alternative that comes to mind is using a stored procedure for the update operations. Anyway, I need to do some research on passing Java objects to stored procedures. Thanks, Shyam --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > Do you have a deadly embrace? > Maybe just syncronise w/ semaphorse or the like. > .V > > Shyam A wrote: > > Vic, > > > > Thanks again. I'm not in a position to switch to > > IBatis as my application is currently in use. > Right > > now, I'm manually killing the user sessions which > lock > > up the table in the database. My database is > Oracle > > 9i, and this problem seems to occur only with > large > > numbers of concurrent users. In my DAO,I update > three > > tables as part of a transaction - table A and/or > table > > B (in loops), and table C. Commit operation is > done > > only after all tables are updated successfully. > So, it > > may be possible that the DBMS locks up rows of > table A > > or B (before commit) and waits until it updates > table > > C for the commit. Is this the cause of the > problem? > > > > I've not been able to determine (using SQl Plus, > TOAD > > ) which query is causing the row-level lock. > > > > Any ideas? > > > > Thanks, > > Shyam > > > > --- Vic Cekvenich <[EMAIL PROTECTED]> > wrote: > > > >>Is there a way you can reproduce this w/ iSQL > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! Search - Find what you're looking for faster http://search.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
