--- In Firebird-Java@yahoogroups.com, Roman Rokytskyy <roman@...> wrote:

>
> >> This is triggered by an IOException as well, unfortunately I didn't
> >> include it for this Exception. However, this IOException should be
> >> logged if you have logging setup and enabled on debug level.
> >>
> >> The stacktrace you sent earlier was with iscStartTransaction as well,
> >> but then during the send of the transaction start operation, now it is
> >> failing after the operation has been sent, but during the receive of the
> >> response from the server. Is there anything in the logs of Firebird?
> >>
> >> I will review the transaction code. Do you by any chance use a custom
> >> transaction parameter buffer or transaction configuration?
> >>
> >> Mark
> >> --
> >> Mark Rotteveel
> >>
> > I'm just using plain DataExpress components without any transaction. And these Exceptions occurs on read operations.
> >
> > And seems that default transactionisolation is READ_COMMITED. Do you think its a good idea to experiment with this parameter?
>
> 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.