> > Well, as it seems it is *not* reliable since the JDBC driver does not
> do a FETCH. I assume that the driver has no fault but instead GlassFish
> is not really asking it to do a fetch?
> So far, I have not seen any other jdbc-driver doing so.
That may be the case -- but it is what Sybase told me and what I can read in Sybase's log.
> Validation would be done for every get connection. It will have (more)
> performance impact if it were to scroll through the results. Wouldn't a
> select query be enough ?
It would be enough to scroll to the first row -- the driver obviously cannot skip THAT. I do not think that scrolling to the first row will be a actually problematic performance drawback.
> > Unfortunately due to technical reasons I really need to check exactly
> for that specific table -- it is a proxy forwarding to another server,
> so it is my only chance. All the other modes do not help me.
> Interesting. What happens if you do
> select count(*) from TABLE_THAT_IS_PROXY on a simple java client ?
I will get the result, obviously.
> I
> would expect that the jdbc-driver will not communicate with the server.
Why not? How shall it return the count without talking to the server?
> What happens if you give the actual table name instead of proxy table ?
That will not work since the actual table is in a different server.
> > So my question is: WHY is GlassFish not really fetching data from the
> driver in the table mode?
> Please refer my first response above.
I expect you mean the performance reason. But what performance difference do you measure between PREPARE and PREPARE+SCROLL TO FIRST ROW?
Regards
Markus
>
> Thanks,
> -Jagadish
> >
> > Thanks
> > Markus
> >
> > >
> > > Thanks,
> > > -Jagadish
> > >
> > >
> > > On Tue, 2008-10-28 at 08:15 +0100, Markus Karg wrote:
> > > > Dear Community,
> > > >
> > > >
> > > >
> > > > it seems as if the "table" method for JDBC Connection Validation
> just
> > > > checks whether the SQL is correct, but not really tries to fetch
> any
> > > > data from that table. The problem is that this is completely
> answered
> > > > by the JDBC driver of my dbms, even if the connection is broken!
> How
> > > > can I tell GlassFish that it really must fetch data?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Markus
> > > >
> > > >
> > > >
> > > > QUIPSY QUALITY GmbH & Co. KG
> > > >
> > > > Ein Unternehmen der MES-Gruppe
> > > >
> > > > Stuttgarter Strasse 23
> > > >
> > > > D-75179 Pforzheim
> > > >
> > > > Tel: 07231-9189-52
> > > >
> > > > Fax: 07231-9189-59
> > > >
> > > > www.quipsy.de
> > > >
> > > > karg_at_quipsy.de
> > > >
> > > > Registergericht Mannheim HRA 701214
> > > >
> > > > Geschäftsführer: Nils Schroeder
> > > >
> > > >
> > > >
> > > > Diese E-Mail enthält persönliche, vertrauliche und vor Weitergabe
> > > > geschützte Informationen und ist ausschließlich für den
> vorgesehenen
> > > > o.g. Empfänger (Adressaten) bestimmt. Falls Sie diese E-Mail
> > > > versehentlich erhalten haben und nicht der vorgesehene Empfänger
> > > sind,
> > > > bitten wir Sie, die E-Mail und deren Anhänge nicht aufzubewahren,
> > > > nicht zu vervielfältigen, nicht zu nutzen und nicht
> weiterzugeben.
> > > > Bitte informieren Sie uns als Absender über diesen
> Zustellungsfehler
> > > > und löschen Sie die E-Mail.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----------------------------------------------------------------
> ----
> > > > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > > > For additional commands, e-mail: users-
> help_at_glassfish.dev.java.net
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net