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 jdbcKona
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 jdbcKona 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 jdbcKona 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.
Problems saving a TableDataSet
I'm using a dbKona TableDataSet to insert some records into a Sybase
DBMS. I'm getting the following error when I try to save the
TableDataSet:
java.sql.SQLException: Length 2107
Exceeds the SQL Server limit of 255
The data you are trying to save is longer than 255 bytes. There are two
SQL Server types (Text and Image) that support data longer than 255
bytes, but there are no methods in the current JDBC
specification that support updates to columns of the corresponding JDBC data
types (Longvarchar and Longvarbinary).
Being able to update Longvarchar and Longvarbinary columns is valuable
enough that we have supplied a public method for it that is not part
of the JDBC API. You can read the details and see a code example in
the jdbcKona/Sybase notes in the section, "Working with Text and Image
types," in the developers guide for jdbcKona/Sybase and
jdbcKona/MSSQLServer.
If this feature is important to your project, please contact jdbc@wombat.eng.sun.com
and ask that it be added to future revisions of the JDBC spec.
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.
Why does getTableName() return an empty string?
It bothers me that the getCatalogName() and getSchemaName() methods do not work, since these two
methods return "database" and "owner" if you use the JDBC-ODBC
bridge
from JavaSoft to connect to a Microsoft SQL Server database. It seems
to me that the actual database and owner should be returned by these
ResultSetMetaData methods. But what really bothers me is that the
getTableName() method returns
an empty string. Why is that?
One of the challenges in implementing JDBC
is that JDBC is based on SQL-92, and there is no DBMS system currently
on the market that actually implements all of
SQL-92. There is no way to implement the getTableName() method in either Microsoft or Sybase SQL
Server, because the underlying vendor API (DB-Library) does not provide
this information. Sybase System 10/11 (not Microsoft) does support
SELECT WITH BROWSE, which returns the table name for any column that
came from an actual table in the browse select list. Table information
is available only with the DB-Library call "dbcolsource()", which is also
Sybase only (not Microsoft). Consequently we decided against
implementing the getTableName() method.
The SQL-92 concept of a "Catalog" is not supported in SQL Server. It
uses instead the sys* tables
(sysobjects, etc.) in each database, which does not map easily to
Catalog.
The concept of a "Schema" is support in Sybase System 10 and 11 (not
in Microsoft). We could only return a string such as "user," which
would not be meaningful. In Sybase System 10 and 11 you can create
objects with a Schema, but the Schema name is used only to drop them
in a single transaction.
