|
|
|
|
|
|
| | | |
FAQs: dbKona
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.
Because 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 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.
How does performance compare between dbKona and raw SQL through JDBC?
dbKona is very lightweight. It will cause 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, because 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 dbKona TableDataSet when I save changes?
After you save changes to a TableDataSet, the results are left intact and you can continue to step through its records with the fetchRecords() methods.
You should be able to save the TableDataSet on a JDBC connection that is not the same JDBC connection you used to populate the TableDataSet with 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.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|