Hi Alexander,
you're very helpful. Unfortunately I think we didn't track the issue down
yet. Please read on...
> Hello Robert,
>
> > These are the entries that deal with timeouts:
> >
> > 2004-10-05 17:25:01 0x988 19651 CONNECT Connection
> > released, T25
> > 2004-10-05 17:25:06 0x988 19651 CONNECT Connection
> > released, T28
> > 2004-10-05 17:40:05 0x988 19637 CONNECT 'vreceive', COMMAND
> > TIMEOUT, T29
> > 2004-10-05 17:40:05 0x988 19651 CONNECT Connection
> > released, T29
> > ...
> > 2004-10-06 09:18:47 0x988 19651 CONNECT Connection
> > released, T28
> > 2004-10-06 09:18:47 0x988 19651 CONNECT Connection
> > released, T31
> > 2004-10-06 09:18:47 0x988 19651 CONNECT Connection
> > released, T30
> > 2004-10-06 09:33:45 0x988 19637 CONNECT 'vreceive', COMMAND
> > TIMEOUT, T25
> > 2004-10-06 09:33:45 0x988 19651 CONNECT Connection
> > released, T25
> >
> > > - I assume you connected with
> > > the default timeout, so look after the SESSION_TIMEOUT
> > parameter of the
> > > database.
> >
> > No, we set it to 900sec (15min). But of course this is less
> > than the period
> > of inactivity.
> >
> > > You did not get the 'session timeout' error because possibly
> > > even the socket was closed already by the server afterwards ...
> >
> > Hm, but if I close the connection via the Database Manager I
> > don't see this
> > error. In fact it seems that the JDBC connection silently
> > reconnects (at
> > least if it's not in a transaction or during reconnect, that's what I
> > conclude from the code in ConnectionSapDB.execute()). And
> > all connections
> > put into the pool are rolled back and reset to autoCommit =
> > true if they are
> > not in autoCommit = true.
>
> Yes, it's the default that it does reconnect when there is a time
> out, and there was no implicit ROLLBACK when this timeout did
> happen.
Hm, I can see your point with the timeout. However, this is strange: every
connection that is drawn from the pool undergoes a livelyness check. It's
basically the execution of a statement returning nothing:
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? Is there some pooling of physical connections done
internally in the driver?
> > How would you explain this? Does the server wait for a
> > certain amount of
> > time after killing a session before it closes the socket?
>
> The x_server waits, and does not close the socket on its own,
> but the OS has the habit of closing TCP/IP connections that
> are too long idle. The exact meaning of 'too long' varies
> and depends possibly on the network components that take
> part in the communication (is that one machine that does
> not work connected by other means to the network, or has it
> an other OS?)
No, it's all local on a Win 2k Server. We're using 7.5.00.18 and the JDBC
driver version that came with it. Do you need additional input?
> We will look and investigate, whether it is possible to detect
> this state, and perform a reconnect (which anyway creates a
> new socket). Perhaps your application also has means to
> configure the pooling such that a Connection object is completely
> discarded after some idle time (> 15 min, but apparantly
> less than approx. 12h).
Thanks for the hint. I'll look into this to see whether this is a feasible
solution.
Kind regards
robert
--
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
