Hello,

Thanks everyone for all the fast responses.

I just tried replacing Interclient with the JCA-JDBC firebirdsql
driver (version 1.0 beta 1) and the first tests seem to surprisingly
suggest that the problem does not occur anymore. I have kept the
exact same setup (using the javaexchange connecion broker) with the
firebirdsql driver and write changes are reflected immediately in the
Java reads now.

Could it be that this is an Interclient issue and that the
Interserver component of Interclient, sets up a read transaction for
each java connection (thus taking a DB 'snapshot') and only commits
the transaction after the connection is destroyed, while the
firebirdsql driver does not? Perhaps a difference in autocommit
implementations ?

I'll try the built in connection pooling now to see if I get the same
results (consistency and speedwise).

We use Firebird SS server version 1.0.

Regards,
Natal Vande Casteele

--- In Firebird-Java@y..., "rrokytskyy" <rrokytskyy@y...> wrote:
> Hi,
>
> > We use the DBConnectionBroker from JavaExchange which always
keeps
> > a certain number of connections open and reuses them. As a
result,
> > if we remotely change the data via MS Access and the ODBC driver,
> > it is NOT reflected in the output of our Java code. The only way
to
> > make the changed data visible is to restart the connection broker
> > (which in our current setup means restarting Tomcat).
> >
> > Has this issue been resolved or is this standard behaviour? Is
> > there a workaround?
>
> As far as I know, currently no solution exists. This problem seems
to
> exist only to one version of the Firebird server on Linux (either
> ClassicServer, or SuperServer, I do not remember) and seems to be
> caused by some specific DPB and TPB that are specified in your case
> by an ODBC driver.
>
> So, I would suggest you to try another version of a database server
> (if you have SS, then try CS).
>
> I do not expect any changes in the engine to solve this issue,
since
> v 1.0 is freezed. When Firebird team releases the 1.5 version, we
> will check the issue again.
>
> Best regards,
> Roman Rokytskyy