I have been thinking about this for a while, but I've been trying to put off expanding the jca wrapper stuff (I have a bunch of ideas in this area; most likely 4.0 stuff).
I don't use Oracle at all. -dain David Jencks wrote: > As slightly less of a hack, how about writing an oracle-driver specific jca > wrapper that takes care of Oracle non-spec compliance? > > You need to modify prepared statement, right? How about the resultset? So > far I haven't wrapped the result set but have been asked to by 2 people. > > BTW do either of you have oracle xa working with jboss 3? > > Thanks > david jencks > > > On 2002.05.19 16:33:22 -0400 Dain Sundstrom wrote: > >>Sacha, >> >>Besides Oracle's drivers being a crap, the CLOB and all SQL 99 types >>could use improvement. Supposedly Oracle's new 9.0.2 drivers fix most >>of these problems. Fixing general Object persistence is the first think >>I will be working on after I finish the docs (this week), so I will look >>at this then. I am even planing on putting a hack in just for Oracle's >>BLOB problems, so I can also put one in for CLOBS. Normally I wouldn't >>put a hack in for a vendor but Oracle it to huge. The flag of this >>option will be some thing <oracle-sucks-and-i-use-it>. =) >> >>-dain >> >>Sacha Labourey wrote: >> >> >>>Hello Dain, >>> >>>I had to look at the JAWS code and how it handled CLOB and have found >>>numerous issues (see my previous post on jboss-dev). >>> >>>I've quickly taken a look at the new ejb2.0 code you implemented and >>> >>saw >> >>>that you're using about the same code for CLOBs. Thus, I think that >>> >>your >> >>>code will have trouble handling CLOBs. >>> >>>Some quick info I found by looking at jaws: >>> >>>- the "read-CLOB" code is actually never used: the code is there but is >>>never reached. The code tests if the field is a string and try to read >>> >>it >> >>>from the recordset by using getString. In Oracle, for example, this >>> >>will >> >>>return null and not raise an exception => null is assigned to the CMP >>> >>field >> >>>even if the CLOB contains data. A check should be added to use the CLOB >>> >>code >> >>>if Type.CLOB has been assigned as the JDBC type of the CMP field. >>> >>>- the "write-CLOB" code handles BLOB and CLOB in the same way => like >>> >>binary >> >>>content. This leads to several problems. >>>First, the String is wrapped in a MarshalledObject and transformed in a >>>byte[] then persisted in the database => the string that is persisted >>> >>in the >> >>>database is unreadable by any other application (because it is >>> >>Java-encoded) >> >>>and no SQL Clob-operators can be used in queries. >>>Second, and this is more an Oracle issue, we have trouble sending back >>> >>a >> >>>Clob to the driver. Either we use preparedStatement.setClob or >>>preparedStatement.setCharacterStream. I've tried to modify JAWS so it >>> >>uses >> >>>preparedStatement.setClob and I have coded a new class that implements >>>java.sql.Clob (and containing the String) that I send to the >>>preparedStatement. Here, we have an Oracle problem: this driver expects >>> >>a >> >>>oracle.sql.Clob object (and is thus not spec compliant): a >>> >>CastException >> >>>occurs. So it doesn't work. Secondly, I've used setCharacterStream. I >>> >>think >> >>>it is the best solution. Nevertheless, we still have a problem: it will >>> >>only >> >>>work with Oracle OCI driver, not the thin driver!!! So I haven't been >>> >>able >> >>>to test the code (but at least it works with thin when strings are < >>> >>2k). >> >>>What do you think? >>> >>>Cheers, >>> >>> >>> >>> Sacha >>> >>> >>>_______________________________________________________________ >>>Hundreds of nodes, one monster rendering program. >>>Now that's a super model! Visit http://clustering.foundries.sf.net/ >>> >>>_______________________________________________ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >> >> >>_______________________________________________________________ >>Hundreds of nodes, one monster rendering program. >>Now that's a super model! Visit http://clustering.foundries.sf.net/ >> >>_______________________________________________ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> > > _______________________________________________________________ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
