On 19-5-2013 12:54, hugo.larson wrote:

>
>
> --- In Firebird-Java@yahoogroups.com, Mark Rotteveel <mark@...> wrote:
>>
>> On 19-5-2013 11:33, hugo.larson wrote:
>>>> Can it be that you use a connection pool and the connection was
>>>> "waiting" in the pool for a long time, then it is accessed and the first
>>>> network operation fails?
>>>>
>>>> In old pool classes there was a property which caused the pool to
>>>> execute some statements that should always work (SELECT 1 FROM
>>>> rdb$database), and if it failed, it recycled the connection before it
>>>> was returned to the application.
>>>>
>>>> Roman
>>>>
>>> Hello Roman,
>>>
>>> No pools are used.
>>> Just plain DataExpress DataBase class that stays open.
>>
>> But how long is that connection open, and how long is it idle? It might
>> indeed be that a timeout occurred and Firebird closed the connection.
>>
>> Mark
>> --
>> Mark Rotteveel
>>
> The connection stays open.
> 1. DX components opens connection of closed.
> 2. The exception occurs in the middle of an operation.
>
> Can it be the case that somehow the connection closes for some unknown reason, from the engine or Jaybird and DX "thinks" its open? But again, there are no problems before this exception happens.

But is there a significant idle time before the connection is used
again? That increases the window for network/timeout issues.

Jaybird currently does not detect that a connection has been closed (eg
by the server, a connection reset, faulty network etc) until the
connection is actually used again. So if the connection isn't being used
for a (very) long time and the server (or something else) closed the
connection, then you will only notice at the time you execute an
operation like starting a transaction.

As Firebird uses TCP keepalive it should not actually be closing the
connection due to timeouts unless the connection between client and
server was unavailable. That leaves potential causes like a bug in
Jaybird, network issues (including proxies/firewalls resetting
connections). Also as you are using a 'non-standard' JVM (Excelsior
Jet), I can't entirely discount that as a potential cause.

Mark
--
Mark Rotteveel