Actually I am giving the thread dump of driver,

while doing an executeUpdate the following trace locks up some statement




at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at
org.firebirdsql.jgds.XdrInputStream.read(XdrInputStream.java:155)
at
org.firebirdsql.jgds.XdrInputStream.readInt(XdrInputStream.java:118)
at org.firebirdsql.jgds.GDS_Impl.nextOperation(GDS_Impl.java:1675)
at
org.firebirdsql.jgds.GDS_Impl.isc_dsql_execute2(GDS_Impl.java:843)
- locked <0x44f11a68> (a org.firebirdsql.jgds.isc_db_handle_impl)
at
org.firebirdsql.jca.FBManagedConnection.executeStatement(FBManagedConnection.java:787)
at
org.firebirdsql.jdbc.FBConnection.executeStatement(FBConnection.java:1100)
at
org.firebirdsql.jdbc.FBPreparedStatement.internalExecute(FBPreparedStatement.java:421)
at
org.firebirdsql.jdbc.FBPreparedStatement.executeUpdate(FBPreparedStatement.java:137)


For this statement other thread waits, but the above threads doesn't
return and stays there itself.

second thread:

at
org.firebirdsql.jgds.GDS_Impl.isc_dsql_allocate_statement(GDS_Impl.java:715)
- waiting to lock <0x44f11a68> (a
org.firebirdsql.jgds.isc_db_handle_impl)
at
org.firebirdsql.jca.FBManagedConnection.getAllocatedStatement(FBManagedConnection.java:745)
at
org.firebirdsql.jdbc.FBConnection.getAllocatedStatement(FBConnection.java:1095)
at
org.firebirdsql.jdbc.FBStatement.prepareFixedStatement(FBStatement.java:996)
at
org.firebirdsql.jdbc.FBStatement.internalExecute(FBStatement.java:986)
at
org.firebirdsql.jdbc.FBStatement.executeUpdate(FBStatement.java:184)


Is there anything like we have to with the DB handle or something like
that, or how we can we solve this problem

regards,
rajagopal










--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:

> > While doing a executeUpdate of some query, the Driver locks the db
> > handle in a synchronized block. At the same time say u want to execute
> > some other query, then the second executeQuery waits for the
> > connection's statement locked by the previous one, then it waits for
> > ever because the locked connection by the previous query doesn't
> > return.
>
> Do you run multiple threads? If yes, why your previous query does not
> return? synchronized() block will be left sooner or later unless
> there's endless loop inside (which isn't, since it works in normal

case).

>
> > This happening so frequently. Kindly pour me some light over this.
>
> Please, post your code here, it is hard to suggest something without it.
>
> Roman