Subject | JDBC disconnects by itself |
---|---|
Author | pp0475 |
Post date | 2004-11-04T09:19:18Z |
Hi,
I'm implementing a batch job application which reads text files and
then saves the data to database. I'm using the newest released
firebird 1.5.4 JDBC-driver, database engine is Firebird 1.5.1 SS on
Linux platform, at the moment I use jdk 1.4.2
Sending SELECT statements to database works fine, but then when I
start to work with INSERT -statements I will encounter a nasty problem:
Using AutoCommit property on I can do ~200 INSERT statements, and then
the driver disconnects the connection by itself, and I'll get an
exception:
org.firebirdsql.jdbc.FBSQLException: Connection
org.firebirdsql.pool.PooledConnectionHandler@3468f4 was closed. See
attached exception to find the place where it was closed
StackTrace:
at
org.firebirdsql.pool.PooledConnectionHandler.invoke(PooledConnectionHandler.java:212)
at $proxy0.isClosed(Unknown Source) ...
When I turn AutoCommit off, I can INSERT ~100 records before the same
exception.
What could be a problem, is there any settings which could affect to
this behaviour or is there a bug in JDBC-driver?
I'm implementing a batch job application which reads text files and
then saves the data to database. I'm using the newest released
firebird 1.5.4 JDBC-driver, database engine is Firebird 1.5.1 SS on
Linux platform, at the moment I use jdk 1.4.2
Sending SELECT statements to database works fine, but then when I
start to work with INSERT -statements I will encounter a nasty problem:
Using AutoCommit property on I can do ~200 INSERT statements, and then
the driver disconnects the connection by itself, and I'll get an
exception:
org.firebirdsql.jdbc.FBSQLException: Connection
org.firebirdsql.pool.PooledConnectionHandler@3468f4 was closed. See
attached exception to find the place where it was closed
StackTrace:
at
org.firebirdsql.pool.PooledConnectionHandler.invoke(PooledConnectionHandler.java:212)
at $proxy0.isClosed(Unknown Source) ...
When I turn AutoCommit off, I can INSERT ~100 records before the same
exception.
What could be a problem, is there any settings which could affect to
this behaviour or is there a bug in JDBC-driver?