db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean McCully <sean_mccu...@yahoo.com>
Subject Re: Transaction Locking
Date Mon, 06 Dec 2004 18:57:32 GMT
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 <skambha@Yngvi.Org> 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.
> This link talks about  types and scope of locks in
> derby -
> Sunitha.

Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.

View raw message