Informix access from Java
Posted in 1997
Topics: Performance & Tuning, Connectivity: ODBC / JDBC / .NET, Platform-Specific Issues, Java & JDBC Development
I am new to this list, but I have looked at recent posting for Informix and JDBC. I could not find an answer to my question. While I can meet other Informix access needs for Java, the one I am having trouble with is described below. Sun SPARC multiprocessor Solaris 2.5.1 or 2.6 Solaris threads Informix DS Online 7.22 Java with a JIT Java *application* access to Informix (this is not an applet or web server, but an application). The applications and the database are coresident on the same host. We have been using JDBC for development. For the JDBC driver so far we have been using the JDBC-ODBC bridge. While this has been functionally OK (with workarounds!), it is somewhat slow. I would like to find a better solution. I've tried Intersolv, Connect, OpenLink, Weblogic, Trifox, and maybe a few others. Either they don't make a driver for Informix (yet) or the performance is not good enough. The requirement: A multithreaded Java program can access Informix on the same host. This program will use a JIT and use Solaris Threads. This will have to run on SPARC and use either Solaris 2.5.1 or 2.6 (which one is TBD). Everything has to be thread-safe and work properly on a multiprocessor. This is a JDK 1.1.x program. It runs with Informix 7.22 DS Online. Reliablilty is extremely important. This has to be a supported product. Non-requirements: Driver (or whatever) is downloadable. Small footprint. No extra processes. There is no requirement on the "type" of driver (e.g., type 2). Preference: Use a JDBC driver that works well with Informix. This has to be in the same environment as above (multiprocessor SPARC, Solaris 2.x, JIT, Solaris Threads). I'd like to see 2-5 times the read performance of the JDBC-ODBC bridge for simple queries, with update performance similar to what I see with the bridge. While reliability is absolutely required, it is also important what the performance is. We don't care about the type of the JDBC driver. We'll use ODBC, a three tier, or whatever. However, the reliability and performance will be the important factors in the choice. We currently use multiple concurrent connections to the same database instance (a set of processes) but to different databases. We have discovered that this is not supported by all JDBC drivers. We would rather keep it this way, but I think we can change to use a single connection to a single database. Acceptable: Non-JDBC access to the database. Again, this has to have the same environment.