Hello Robert,
could you retrieve the specific driver version (I'm quite sure, but to be safe,
tell me what 'java -jar sapdbc.jar -V' did print out).
> Statement stmt = conn.createStatement();
> ...
> stmt.executeQuery("SELECT * FROM check_table WHERE 1 = 2").close();
>
> Now, *if* the connection did timeout, then this line should trigger an
> exception and the connection is never returned from the pool
> but instead
> discarded. If there is no valid connection in the pool, a new one is
> created. But why then would the new connection throw this
> exception, as it
> was just (i.e. n seconds ago with n < timeout) created?
>
> Also, our code has a level of fault tolerance: we're using prepared
> statements and if an execution fails, the prepared statement
> is closed, the
> connection dropped and a new connection is obtained. Then a new PS is
> created etc. Strangely enough the second attempt (with the
> new conn) yields
> the same error as the first attempt. How can it be that a
> new connection
> has this problem?
This all together tells that it is probably not a timeout itself, but
a network error in the resolution of a timeout error. The stack backtrace
comes from the CONNECT statement of the 'silent' reconnect, *but* this
statement is not the first packet sent to the server ...
> Is there some pooling of physical connections done
> internally in the driver?
No.
Regards
Alexander Schr�der
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
