Technical FAQ: Questions about dbKona
FAQ Index
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. WebLogic jDriver
drivers and WebLogic
JDBC implement the JDBC 1.22 specification.
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
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 multitier pure-Java JDBC driver, WebLogic JDBC, makes 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 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.
