Review whether it makes sense to extend JDBC_PING2 in the first place

[rhusar]

Review what are we getting from extending JDBC_PING2 in the first place.

This is very problematic because the protocol inherits a lot of SQL-specific properties from JDBC_PING2, insert_single_sql, jndi names, datasources, etc. that are NOT usable.

The price we pay is fragility and tight coupling to a JGroups version.

[rhusar]

@rsobies perhaps can elaborate on the thought process here?

[rhusar]

What we get:

• connection_url
• lock and reads counter for stats (problematic also due to no locking)
• The overall discovery flow orchestration

What we need to workaround:

• loadDriver() - no-o
• createInsertStoredProcedure() - no-op
• getConnection() - returns null (yuck)
• delete(Connection, ...) and ignore conn

What we cannot fix nor override:

• all SQL properties insert_single_sql, clear_sql, select_all_pingdata_sql, datasource_jndi_name, etc

Using FILE_PING is also problematic as its file-system oriented

• Paths, directories, file reads/writes
• readFromDir()
• writeToFile()
• "location" as a directory path

So, unless we @belaban have something that is truly reusable like abstract database ping, we need to extend Discovery directly.

[belaban]

I agree