db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert J. Carr" <rjc...@gmail.com>
Subject Re: locking problem
Date Tue, 21 Jul 2009 21:14:49 GMT
Hi Knut, et al.-

So now, with your help, I can see the exact statement that is failing,
with the exact parameters that are being passed into the prepared
statement.  However, this is only giving me the "where", but I need to
know the "how" and more importantly the "why".

Superficially, the statement parameters don't look any different than
any other time it is used.  Nor are there any logs around the failed
statement to give any clue as to what is going wrong.  The only
difference is there is a log that says "Cleanup action starting" and
then there's a subsequent log that says "Failed Statement is:" and
gives the failed statement.

Again, in the lock table dump, all I'm seeing is this:

*** The following row is the victim ***
9526      |ROW          |X   |0        |(2,43)  |WAIT |T |NULL  |SG_TRACKS
*** The above row is the victim ***

Maybe the (2,43) is a clue?  Does this have anything to do with the
row and column numbers?

My point is, I have a lot of logging information and stack traces, but
still nothing is telling me why this happened.  Can someone explain
how derby can even get into a WAIT ROW LOCK without involving
concurrency?  I'm beginning to think this *might* be a derby problem
(but I've learned to eat similar words many times :) ).


On Tue, Jul 21, 2009 at 1:19 PM, Robert J. Carr<rjcarr@gmail.com> wrote:
> Hi Knut-
> It looks like things are being written to derby.log, but just not the
> derby.log I was familiar with.  There's another derby.log file written
> into a tomcat directory that looks to have the information I'm looking
> for.
> I'm inspecting it now ... thanks for the guidance!
> Robert
> On Fri, Jul 17, 2009 at 3:09 AM, Knut Anders Hatlen<Knut.Hatlen@sun.com> wrote:
>> "Robert J. Carr" <rjcarr@gmail.com> writes:
>>> Hi Knut-
>>> I've returned from a short holiday and hoping you could help me out a
>>> bit more.  I think the flag you suggested is what I'm looking for, but
>>> I don't know where to track down the logs.  I create my database using
>>> ant and then later use it in tomcat.  When I create the database a
>>> 'derby.log' file is written into the same folder as my build.xml.
>>> Here are the contents of that file:
>>> ----
>>> 2009-07-08 23:30:54.701 GMT:
>>>  Booting Derby version The Apache Software Foundation - Apache Derby -
>>> - (764942): instance a816c00e-0122-5cb4-9604-0000000f49d8
>>> on database directory /Users/rjcarr/...
>>> Database Class Loader started - derby.database.classpath=''
>>> ----
>>> However, after it is created, nothing is added to it.  So I'm not sure
>>> where to look to find these logs.  This link:
>>> http://publib.boulder.ibm.com/infocenter/cscv/v10r1/index.jsp?topic=/com.ibm.cloudscape.doc/rtunproper43517.html
>>> Says it is written to the "information log", but I don't know what that is.
>>> When I added this flag:
>>> derby.locks.deadlockTrace=true
>>> The logTable dump (which I've posted earlier) is embedded into the
>>> stack trace.  Looking at the stack trace after adding the flag you've
>>> suggested I don't see anything different.
>>> So, long story short, where do I find these log entries?
>> Hi Robert,
>> Sorry for the late reply.
>> derby.log is where you should find these entries. How did you set the
>> property? One difference between derby.locks.deadlockTrace and
>> derby.language.logStatementText is that the former is dynamic and the
>> latter is static, meaning that if you set d.l.logStatementText with
>> SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY, it won't take effect until you
>> have rebooted the database.
>> Does it work if you create a file called "derby.properties" in the same
>> directory as where you found derby.log and add the lines below to it?
>> derby.language.logStatementText=true
>> derby.locks.deadlockTrace=true
>> Then, after creating/using the database, derby.log should contain
>> entries similar to this one for each statement you have executed:
>> 2009-07-17 10:05:26.608 GMT Thread[main,5,main] (XID = 144), (SESSIONID = 0), (DATABASE
= db), (DRDAID = null), Begin compiling prepared statement: create table t(x int) :End prepared
>> 2009-07-17 10:05:26.703 GMT Thread[main,5,main] (XID = 144), (SESSIONID = 0), (DATABASE
= db), (DRDAID = null), End compiling prepared statement: create table t(x int) :End prepared
>> 2009-07-17 10:05:26.716 GMT Thread[main,5,main] (XID = 144), (SESSIONID = 0), (DATABASE
= db), (DRDAID = null), Executing prepared statement: create table t(x int) :End prepared
>> --
>> Knut Anders

View raw message