|
| ||||||||||||||||||
 |  |  |  |
This section contains extra information relating to the deployment of the Easysoft JDBC-ODBC Bridge.
The Easysoft JDBC-ODBC Bridge Driver is built with JDK 1.3.
Applications require the Java Runtime Environment (JRE) 1.2 or higher.
Applets require Netscape Navigator 5.x (or higher) or Microsoft Internet Explorer 5.x (or higher).
The Easysoft JDBC-ODBC Bridge runs as a service under Windows NT 4, Windows 2000, Windows XP and Windows Vista.
The Easysoft JDBC-ODBC Bridge will also run under Windows 9x (where services are not supported) when started manually as an application.
| To run the Easysoft JDBC-ODBC Bridge on Windows 95, you need WinSock2, which can be downloaded from ftp://ftp.microsoft.com/bussys/winsock/winsock2/. |
Log onto the Easysoft JDBC-ODBC Bridge Platforms page on the Easysoft website for details of currently available releases.
In addition to support for all JDBC 1.22 methods, the Easysoft JDBC-ODBC Bridge also supports all JDBC 2.1 functions (such as batch updates, scrollable results sets, programmatic inserts, deletes, and updates), except SQL 3 data types.
The JOB Server makes ODBC 2.0 and ODBC 3.0 calls.
The use of a driver manager means that you can connect it to ODBC 2.0 drivers and the driver manager will remap the calls.
As Easysoft recommend the Microsoft driver manager for Windows and the unixODBC driver manager for Unix, if you decide to use a different driver manager then you need to be sure that it supports ODBC 3.0 and ODBC 2.0 calls.
All standard JDBC data types are supported.
The default Easysoft JDBC-ODBC Bridge driver classes are found in:
C:\Program Files\Easysoft\Easysoft JDBC-ODBC Bridge\Jars\EJOB.jar
/usr/local/easysoft/job/EJOB.jar
This location must be added to the classpath in order to compile under Sun's JDK or run under the JRE.
For further information about driver classes and class paths, see http://java.sun.com/j2se/1.4/docs/tooldocs/windows/classpath.html (Windows) or http://java.sun.com/j2se/1.4/docs/tooldocs/solaris/classpath. html (Unix).
The standard Driver Manager methods:
DriverManager.setLogStream(java.io.PrintStream(java.io.PrintStream out))
(for JDBC 1 driver managers)
DriverManager(java.io.PrintWriter out)
(for JDBC 2 driver managers)
can be used in your code to enable or disable tracing to a specified output file.
It is also possible to turn on tracing to the standard output (Java console) by adding the :trace=on attribute to the Easysoft JDBC URL.
Set the clearText=on attribute to disable the default encrypted transmission of connection information, which can make the tracing output unreadable.
For multithreaded applications and applets you should also set the :multi=on attribute, so that each line of the generated trace is prefixed with an indication of the thread that produced that line.
jdbc:easysoft://host/dsn:trace=on:multi=on
Use ODBC tracing on the machine where the JOB Server is installed.
Start the ODBC driver manager administration interface via Start Menu>Control Panel>ODBC Data Sources, click on Tracing, ensure the specified filename is valid and click Start Tracing Now.
See ODBC Tracing for further details.
If you are using the unixODBC driver manager then tracing is enabled in the odbcinst.ini file (usually /etc/odbcinst.ini).
To enable tracing you must add two attributes to the [ODBC] section (if you do not have an [ODBC] section, create one):
Tracing will only work if the user who is running the application to be traced has write permission to TraceFile (and to the directory containing it).
Support for Unicode data in the Easysoft JDBC-ODBC Bridge can be enabled by setting the JDBC URL connection attribute :unicode=on (see Connecting from Java).
Use one of the two getString methods in the ResultSet class to read Unicode data and the setString method in the PreparedStatement class to write Unicode data.
Read and write statements to metadata table, row and column names containing Unicode characters are not supported, unless those names are restricted to ASCII characters only.
The executeQuery method in the Statement class does NOT support SQL containing Unicode character strings.
JOB Server connections are made through the port designated in the connection URL and any firewall must allow TCP protocol traffic on this port.
If the Java client program is an applet then the browser of a user will normally restrict network connections to the host from which the applet was served.
Note that the JOB Driver recognizes a special hostname in the URL, appletHost, which always refers to the host that the applet came from.
Using this hostname means that the name of the server may be changed or the ODBC data source and applet moved without breaking the reference.
For an example of using appletHost, follow the instructions in the Getting Started link at http://www.easysoft.com/products/data_access/jdbc_odbc_bridge/index.html and look at OutputApplet.java.
For general use in browsers, the applet must be stored on the machine where the ODBC data source is set up. If this is not the web server then for low-traffic applications the Web Administrator built into the JOB Server may be used to serve the single page that contains the <APPLET> tag.
For heavier-duty applications it may be advisable to install a fully-fledged web server (such as Apache) on the machine holding the data sources.
Although the JOB Server and ODBC Driver must both be on the machine that serves the applet, the actual database does not have to be running on that same machine. Oracle, DB2, Informix and SQL Server are all examples of such network-enabled databases.
This applet restriction can normally be overcome by providing a signed applet, which a user may choose to "trust", thus allowing access to a wider range of network hosts.
The JOB Client is safe to use in multi-threaded applications and applets. It fully meets the requirements of the ODBC 3.5 specification, with the proviso that the ODBC data source must support asynchronous statement execution (see http://java.sun.com/products/jdbc/driverdevs.html).
All operations on java.sql and javax.sql objects are required to be multi-thread safe able to cope correctly with having several threads simultaneously calling the same object.
In other words, a statement execution in one thread should not block an execution in another thread. In particular, JDBC drivers should operate correctly when used from multiple threads.
An example of a specific use of multi-threading is the way a long-running statement can be cancelled. This is done by using one thread to execute the statement and a second one to cancel it with the method Statement.cancel.
Although in practice most JDBC objects are accessed in a single-threaded way, there needs to be support for multi-threading.
Some database APIs, such as ODBC, provide mechanisms for allowing SQL statements to execute asynchronously. This allows an application to start up a database operation in the background and then handle other work (such as managing a user interface) while waiting for the operation to complete.
As Java is a multi-threaded environment, there is no need to provide support for asynchronous statement execution. Java programmers can easily create a separate thread if they wish to execute statements asynchronously with respect to their main thread.
Some drivers may allow more concurrent execution than others, but developers should be able to assume fully concurrent execution. If the driver requires some form of synchronization, then the driver should provide it. In this situation, the only difference visible to the developer should be that applications run with reduced concurrency.
For example, two Statement objects on the same connection can be executed concurrently, and their result sets can be processed concurrently (from the perspective of the developer). Some drivers will provide this full concurrency, while others may execute one statement and wait until it completes before sending another one.
Under Windows, JOB Server may run in either multi-threaded or multi-process mode:
| Copyright Notice |
| | | |
