[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-java
Subject:    Re: connector mxj can't init db on linux
From:       Eric Herman <eric () mysql ! com>
Date:       2006-04-28 19:13:42
Message-ID: 1146251623.1471.66.camel () localhost
[Download RAW message or body]

Hi Andreas,

On Fri, 2006-04-28 at 14:34 +0200, Andreas Schlicker wrote:

> > I attached two files that contain some sample code that reproduces the 
> > problem on my system.
> 

Great examples! Thanks.

> I tested the sample code on my laptop with Debian and Windows XP and it 
> runs perfectly on this machine. However, I still have the same problem 
> on several workstations running Debian. It looks like a problem of the 
> configuration of the machine.

Unfortunately, they run *perfectly* out-of-the-box for me, too. 

> Do you have an idea what could cause the problem?

I do have a tiny a guess. But I will ask around about it. 

Let me lead with the question: are we seeing failures on multiple CPU
machines? Here is why I ask:

>From http://bugs.mysql.com/bug.php?id=9381
=======================================================
InnoDB locks datafile (ibdata1) when it starts (using fcntl()), and does
not
explicitely unlock it, which means it is unlocked when the mysqld process
terminates, i.e. after the PID file is removed.
So if you send mysqld a shutdown request (kill -TERM or mysqladmin shutdown),
wait for PID file to be gone, and restart mysqld immediately, there is a chance
that the old mysqld is somewhere between removal of PID and disappearance, so
this old mysqld would still have the lock, and the new mysqld would fail to
lock. The machine which exhibits the problem has 2 CPUs and is Linux.
=======================================================

So perhaps what we are seeing is a timing issue? Perhaps if we waited a
moment between execution of the first program and the second program we
would not see the issue.

If this is /not/ the issue, then obviously there is *something*
configuration dependent here. Let's get as much information as we can
about the failing systems and compare it to the working systems.

let's start with a couple of: 
 * Which versions of Debian? ("sarge?") ("stable?")
 * What is the result of "uname -a"
 * Which JVM? 
 * For the record, which version of Connector/J? (This won't make any
difference for this issue, of course.)
 * We aren't running as "root" are we?
 * We're using Connector/MXJ 1.1.6, in all cases, correct?

And anything else you can think of which might help re-create the
environment or might differentiate the failing environments from the
working ones, would certainly be worth looking at, even if they don't
seem like they could possibly make a difference.

This may be a hard one to find, but hopefully it will be simple to solve
once we identify the root cause.

Cheers,
 -- Eric

> 
> Regards,
> Andreas
> 


-- 
Eric Herman, Software Developer
MySQL AB, www.mysql.com
Mobile: +1 206 913 8942

Are you MySQL certified?  www.mysql.com/certification


-- 
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe:    http://lists.mysql.com/java?unsub=mysql-java@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]