![]() |
![]() |
|
WebLogic Frequently Asked Questions: dbKona
What is JDBC? How are JDBC and dbKona related?
Java Database Connectivity (JDBC) is a JavaSoft specification that provides a
standard way for programmers to write Java applications that access databases. Sun
calls JDBC a common base on which higher level tools and interfaces can be built.
dbKona is a higher-level interface than JDBC, but requires a JDBC driver, for
example, one of the WebLogic jDriver JDBC drivers. dbKona provides convenient,
vendor-independent ways to access data. It offers client-side management of query
results and automatic SQL generation. dbKona objects shield the programmer from the
necessity of knowing vendor-specific details in order to work with database data, yet
offer the conformance and interoperability of the JDBC interface. With dbKona, for
example, you can write a single Java application that can talk to multiple,
heterogeneous databases.
Since dbKona is designed to be a plug-and-play API, which is how we support various DBMSes simultaneously, drivers from any vendor that meet the JDBC specification work with dbKona. Any application that uses dbKona will work with any JDBC driver, including WebLogic's JDBC drivers.
WebLogic jDriver products and dbKona give you the best of both worlds: complete compatibility with JDBC and the power of dbKona.
Does dbKona use vendor-specific native libraries?
Does dbKona use vendor-specific native libraries to communicate with a remote
DBMS?
dbKona uses any JDBC driver to communicate with a remote DBMS. In the
two-tier environment, if you use a Type 2 JDBC driver, you need a vendor-supplied
library (or the proper ODBC driver) on each client using your dbKona application. Or
you can use a Type 4 JDBC driver (pure Java) that does not require vendor libraries.
In this three-layer arrangement, dbKona sits on top of the JDBC driver as a higher level
interface. If you use a Type 2 JDBC driver, it makes calls to the vendor library to
access the database.
The WebLogic pool, JTS, and RMI JDBC drivers make calls through the WebLogic Server to the JDBC driver on behalf of dbKona applications or applets, which do not need client-side vendor libraries.
Is there a performance hit from using dbKona?
Is there a performance hit from using dbKona, as opposed to raw SQL through
JDBC? Do you think the added power of dbKona completely outweighs any overhead
it may add?
dbKona is very lightweight. It will cause very little, if any, performance
degradation, compared with the equivalent data retrieval in straight JDBC. Its
advantages far outweigh its overhead: it provides a simpler and more convenient API
for data access, and it gives you access to automatic generation of SQL through a
query-by-example model. You can also do things with dbKona DataSets that you can't
do with a straight JDBC ResultSet, like storing a dbKona TableDataSet in a WebLogic
Server-side client Workspace.
Within WebLogic, your clients may actually perceive better performance, since dbKona gives you tools to manage query results. You can cache data on WebLogic for read-ahead. You can share one set of query results among multiple clients. With an "EventfulTableDataSet," you can even reflect changes to one client in all the clients viewing the same table. dbKona gives you more power over data than straight JDBC, so you can tune your client application for optimum performance.
What happens to a db Kona TableDataSet when I save changes?
When I save changes to a dbKona TableDataSet, are its results left intact? That
is, can I continue to call the fetchRecords(int) method and look at other records in
it? Is there a difference in behavior if I save the TableDataSet on a different JDBC
Connection?
Yes, after you save changes to a TableDataSet, you can continue to step through
its records with the fetchRecords() methods.
Saving the TableDataSet on a JDBC Connection that is not the same JDBC Connection you used to populate the TableDataSet should generally have no effect on the integrity of the data in the TableDataSet. Of course, if the Connection you use to save has some sort of history or state that makes it unusable for updates - for example, if you are in a transactional state that might cause the update to be uncommitted, or cause a deadlock because of locks other Connections have - this will not be true. The DBMS must consider every Connection as an independent application, even if the Connections are cooperating on the client end.
Sometimes I get a license exception with dbKona
When using dbKona in my applet on a client machine, I get the following license
exception:
weblogic.common.LicenseException:
Failed to determine your Host name:null
I thought I didn't need a client-side license for applet use of dbKona.
dbKona doesn't require a license when it is loaded dynamically with the applet
loader. However, if dbKona is installed locally in the CLASSPATH of the client
machine, then you must have a license to use dbKona. If classes used by your applet
exist in the CLASSPATH of the client machine, the applet loader will attempt to load the
classes locally before going across the wire to load classes from the HTTP server.
You can solve this problem by either installing a license on the client machine, or removing the WebLogic classes from the client's CLASSPATH.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|