That is probably the case I have found a bug in my program that for some reason is calling methods repeadetly due to either a problem with Java's repaint on JInternalFrames and JPanels or the actionlistener implemented inside the Frames, if these methods are not being called at the same time but after each other, does Cloudscape unlock the tables on the connection, or if I have the same method and a duplicate connection accessing the Table at same time with autocommit off would this cause the problem, and is there a way to have a connection wait, aside from using seperate threads? And I would guess that increasing the timeout would not help either?
--- Sunitha Kambhampati <[EMAIL PROTECTED]> wrote: > Sean McCully wrote: > > >I am getting the following exception when I try to > >drop a table with AutoCommit off using > >PreparedStatements and executeUpdate(); > >Is this a derby problem? Cloudscape? or should I > use > >another method to execute Drops? > > > >SQL Exception: A lock could not be obtained within > the > >time requested > > > > > > > > > > > > The lock timeout message suggests that the > transaction is not able to > get the necessary locks for executing the drop > table. This can be, if > there is another transaction in the system holding > conficting locks on > the same table. > Can you check and see if that is the case. > > For debugging purposes, setting > derby.locks.deadlockTrace=true will > write a detailed list of locks at the time of the > timeout to be written > into derby.log. > http://incubator.apache.org/derby/manuals/tuning/perf79.html#IDX545 > > This link talks about types and scope of locks in > derby - > (http://incubator.apache.org/derby/manuals/develop/develop74.html#IDX696) > > Sunitha. > > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
