JDBC Type 2 drivers: do they connect through the native API of the target DBMS? Decide whether the statement is correct, and consider deployment implications.
-
AValid (Type 2 uses a native DBMS API accessed from Java)
-
BInvalid (Type 2 is a pure Java thin driver)
-
CDepends on whether ODBC is installed
-
DValid only for embedded databases
-
EApplies exclusively to Oracle databases
Answer
Correct Answer: Valid (Type 2 uses a native DBMS API accessed from Java)
Explanation
Introduction / Context: Knowing the differences among JDBC driver types helps diagnose classpath/native library issues and informs deployment strategies. Type 2 drivers are distinct because they rely on native client libraries provided by the DBMS vendor.
Given Data / Assumptions:
- The claim: “Type 2 drivers connect to the native API of the DBMS.”
- We compare this to the canonical JDBC driver taxonomy.
- We consider cross-platform deployment constraints.
Concept / Approach: Type 2 drivers are part Java and part native code; they call a DBMS’s native client API (for example, Oracle OCI). This requires installing the vendor’s client libraries on the host. In contrast, Type 4 drivers are pure Java and speak the database wire protocol directly. Thus, the statement about Type 2 is correct.
Step-by-Step Solution:
Identify that Type 2 requires vendor native libraries.Map consequence: environment must ship matching native binaries.Contrast with Type 4 which avoids native dependencies.Conclude the claim is valid.Verification / Alternative check: Attempt to load a Type 2 driver without native libs results in UnsatisfiedLinkError; installing the vendor client resolves it.
Why Other Options Are Wrong:
- Type 2 is not pure Java thin; ODBC is unrelated to Type 2; it is not restricted to a single vendor or embedded databases.
Common Pitfalls: Packaging apps without required native libraries; confusing Type 2 with the deprecated Type 1 bridge.
Final Answer: Valid (Type 2 uses a native DBMS API accessed from Java)