Subject | RE: [IB-Java] Re: problems with connections in v1.6 |
---|---|
Author | Peter Wilkinson |
Post date | 2000-08-10T08:51:54Z |
Thanks Torsten,
I don't have much time to try this properly before the weekend, so I'll
probably give it a go some time on Saturday and report back.
PeterW.
-----Original Message-----
From: Torsten Welches [mailto:torsten.welches@...]
Sent: Thursday, 10 August 2000 6:18 PM
To: IB-Java@egroups.com
Subject: [IB-Java] Re: problems with connections in v1.6
I don't have much time to try this properly before the weekend, so I'll
probably give it a go some time on Saturday and report back.
PeterW.
-----Original Message-----
From: Torsten Welches [mailto:torsten.welches@...]
Sent: Thursday, 10 August 2000 6:18 PM
To: IB-Java@egroups.com
Subject: [IB-Java] Re: problems with connections in v1.6
--- In IB-Java@egroups.com, "Shaunak Mistry" <smistry@i...> wrote:
> Peter Wilkinson wrote:
> >
> > Hi,
> > I'm trying to debug a strange situation when using the following:
> > JRun Servlet Engine 3 with a pool of connections -> Interclient
1.6 ->
> > Interbase SuperServer 6 all on the same machine and all running
on Linux
> > (I've tried Sun's JDK and IBM JDK both v1.3)
>
> Peter,
>
> Interclient 1.6 has been certified with JDK 1.2 not 1.3. Have you
> tried it with JDK 1.2?
<snip>
> If this is happening with JDK 1.2 then it should be a bug in IC.
I doubt that this is a 1.2 vs. 1.3 problem. There's nothing
new/changed in 1.3 I could think of that would cause problems like
the described. In fact IC16 does not even use any JDK 1.3 or 1.2
features, not even 1.1! I guess you could still compile IC16 under
JDK 1.0, that's why so many deprecations show up under 1.1 and higher.
Having said that I also doubt that it is a bug in IC itself. Since
InterClient does not talk to the Interbase server directly it is not
likely that it can lock it up. IMO InterServer would be a more likely
candidate.
If it would be a JRun/InterClient threading problem (e.g. deadlock)
JRun and the affected InterClient connection would lock, but why
would Interbase?
BTW - InterServer (I'm under NT) spawns a whole new NT-Process
(rather then only a new thread as I had expected) for each
InterClient connection. Why is that?
Here's a test to do multi-threaded InterClient connections to
InterServer. I did not have any problems, even with a bigger number
(say 50) of concurrent connections. Maybe you can use it for your
debugging, Peter. I run it both under 1.2.2 and 1.3
Regards,
Torsten
-----
public class Tester {
private static java.util.ArrayList threadList = new
java.util.ArrayList();
private static final int THREAD_COUNT = 5; //how much threads do we
want to spawn?
private static final int SECONDS_TO_RUN = 30; //how long should the
threads run?
static public void main (String args[]) {
for (int i = 0; i < THREAD_COUNT; i++) {
ThreadedSelect newSelect = new ThreadedSelect("ThreadedSelect"
+ i);
newSelect.start();
threadList.add(newSelect);
}
try {
//let the ThreadedSelects run for SECONDS_TO_RUN seconds
Thread.currentThread().sleep(SECONDS_TO_RUN*1000);
} catch (InterruptedException ignore) {
} finally {
System.out.println("shutting down");
killAllThreads();
}
}
private static void killAllThreads() {
while (threadList.size() > 0) {
ThreadedSelect t = (ThreadedSelect)threadList.get(0);
t.stopMe();
threadList.remove(t);
}
}
static class ThreadedSelect extends Thread {
private boolean stopRequested = false;
public ThreadedSelect(String aName) {
super(aName);
}
//Thread started
public void run() {
int runCount = 0;
while (!stopRequested) {
runCount++;
interbase.interclient.DataSource dataSource = new
interbase.interclient.DataSource();
dataSource.setDatabaseName
("c:/programme/Borland/InterBase/examples/database/employee.gdb");
try {
java.sql.Connection c = dataSource.getConnection("sysdba",
"masterkey");
java.sql.Statement stmt = null;
java.sql.ResultSet results = null;
System.out.println(getName() + ": connection no " +
runCount);
try {
stmt = c.createStatement();
results = stmt.executeQuery("Select JOB_TITLE from JOB
where JOB_GRADE=5");
while (results.next()) {
results.getString(1); //dummy-reads - just to do
something
}
} finally {
if (results != null) results.close();
if (stmt != null) stmt.close();
if (c != null) c.close();
}
} catch (java.sql.SQLException e) {
System.out.println("sql exception: " + e.getMessage());
}
}
System.out.println(getName() + " dies");
}
public synchronized void stopMe() {
stopRequested = true;
}
}
}
To unsubscribe from this group, send an email to:
IB-Java-unsubscribe@egroups.com