When possible, one should choose thin driver over OCI. The benefits are:
1) Using thin client, you'll never have Dr. Watson: access vioation error(c0000005). One of the reasons that java is better than C is you don't need to worry about the annoying malloc and dealloc anymore. In other words, in java app, you won't see the crashes such as Dr. Watson: access violation or coredump: signal 11 segmentation violation. I have a client who was using Oracle 9.2.0.5 and they were experiencing intermittent tomcat mid-tier crashes. The Dr. Watson log clearly pointed the access violation that led to the crash happen to a OCI call, the Oracle function name is something like "kpuhhalo", seems like the function to allocate memory. Oracle reviewed it and didn't find problem in OCI code and said you'd better upgrade to 9.2.0.8 because that is the supported version. So they went to 9208, still got crash, the new offending method was "kpuhhfre", seems the function to free memory. After spending one month to convincing Oracle support this is a Oracle bug and got developer to review the problem, the answer was something like "I can investigate the problem for you but don't count on me, it'll take long time to diagnose." In the meantime, I ran into a similar crash in a test environment. Because it was test environment, I had more control of it, I changed code to use thin JDBC, the job didn't succeed, but there was no crash and it did give me a error message "ora-01000:maximum cursor exceeded". So what happened previously must be OCI driver experiencing some anomaly because too many cursors were opened, but before it reached max open cursor when Oracle would report a clear error message, OCI died in memory allocation/dealloc routine because of C code is fragile, especially when boundary condition, like in our case, approaching maximum cursor.
2) The configuration and deployment is much easier, just one jar file, otherwise you'll have to install either whole Oracle client or oracle instant client.
One major problem of using thin jdbc was it doesn't support standard stream jdbc interface for LOB, you'd have to use lob locator. In 10g jdbc, the problem is solved by the
introduction of SetBigStringTryClob property.
Since I haven't seen formal report claiming OCI is faster than thin, I guess even if OCI does have a performance superiority, it is marginal. I'd trade marginal performance gain for less mysterious crashes and easier config/deployment on any given day.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment