Corporate Info | News | Solutions | Products | Partners | Services | Events | Download | How To Buy
Frequently Asked Questions: Previous topic | Next topic | Contents

WebLogic Frequently Asked Questions: dbKona

FAQ Index

- What about JDBC and WebLogic dbKona?

- Does dbKona use vendor-specific native libraries?

- Is there a performance hit from using dbKona?

- What happens to a db Kona TableDataSet when I save changes?

- Sometimes I get a license exception with dbKona

What about JDBC and WebLogic 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. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.