Hi Markus,
On Wed, 2008-10-29 at 19:25 +0100, Markus Karg wrote:
> Steve and Jagadish,
>
>
>
> I am sorry, I did not read carefully. So GlassFish does EXECUTE
> "SELECT COUNT(*)"? It's pretty strange that the driver can answer this
> without a server roundtrip! In fact, in my DBMS server log I do not
> see this call. Pretty strange. Or does GlassFish just PREPARE that?
GlassFish prepares, executes the query and gets the resultset. But it
does not scroll through the resultset.
> The preparation can be done by the driver, since it can buffer the
> meta data.
>
>
>
> Actually I think (but I do not have a proof) that PREPARE will work
> the same for BASE and PROXY tables, while EXECUTE obviously will work
> different. But anyways, why not just doing a simple SELECT 1 FROM
> Table and scroll to the first row? The performance is not measurable
> worse.
>
>
>
> Sad but true: We switched from JOnAS to GlassFish due to all the bugs
> in JOnAS. But JOnAS allows to enter not only a table name, but a
> complete SQL to execute... so maybe this is a good feature proposal
> for future?
Yes, we are planning to provide custom validation mechanisms, where the
administrator can provide a validation query of his own, in v3.
Hope this would help.
Thanks,
-Jagadish
>
>
>
> Regards
>
> Markus
>
>
>
> From:Steve.Essery_at_Sun.COM [mailto:Steve.Essery_at_Sun.COM]
> Sent: Mittwoch, 29. Oktober 2008 18:40
> To: users_at_glassfish.dev.java.net
> Subject: Re: JDBC Connection Validation
>
>
>
>
> Markus Karg wrote:
>
> Table based validation will do a
> select count(*) from table. Yes, its the jdbc-driver that is not doing
> fetch from database.
> * What database and driver do you use ?
>
>
> Sybase SQL Anywhere 11.0, iAnywhere driver
>
>
> There are two other modes, auto-commit and meta-data. Now a days, these
> are cached by several jdbc drivers and the reliable mode is 'table'.
> http://blogs.sun.com/JagadishPrasath/entry/connection_validation_in_gla
> ssfish_jdbc
>
>
> 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?
>
>
> Most JDBC drivers contact the server to parse and validate that the
> SQL is actually correct, and that the tables that are part of the
> query exist, and have the columns that are referenced. If the
> connection is unable to communicate with the backend server then the
> JDBC driver would throw a SQLException back.
>
> From the sounds of things Sybase's driver is deferring the parse until
> actual execution. Or its because a Sybase proxy table is really a
> stored procedure which executes and fetches from the remote database
> that is confusing things. I don't have access to Sybase - but I do
> wonder if validation works with a regular table in the local database
> the application server connects to, i.e. is it a problem for all
> tables or just proxy tables?
>
>
>
>
>
> * Probably, you can try these other modes and see whether the issue is
> resolved.
>
>
> 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.
>
> So my question is: WHY is GlassFish not really fetching data from the driver in the table mode?
>
> 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
>
>
>
>
>
>
>