AppletTalk.com Java discussions newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Oracle specific jdbc and J2EE application server          AppletTalk.com Forum Index -> Java and Databases View previous topic :: View next topic   Author Message kimtiede@gmail.com Guest Posted: Thu May 12, 2005 8:56 am    Post subject: Oracle specific jdbc and J2EE application server Hi there, We need to use the Oracle specific jdbc features such as mapping an Java object to a Oracle Type and for that reason we need to cast the connection and statements returned from the jndi datasource to Oracle extensions, such as the code below: CallableStatement cstmt = conn.prepareCall(sql); OracleCallableStatement ocs = (OracleCallableStatement)cstmt; ocs.setORAData(1, gepjList); ocs.setInt(2, afsenderID); ocs.executeUpdate(); Unfortunately it seems that J2EE application servers seems to wrap the inner connection to the Oracle database and we get a classcast exception. The http://jakarta.apache.org/commons/dbcp framework allows you to setAccessToUnderlyingConnectionAllowed to true and thereby getting the innermost delegate. Is there a similar feature on a J2EE application server or is there another workaround? Thanks in advance Cheers Kim Back to top Manfred Rosenboom Guest Posted: Thu May 12, 2005 10:54 am    Post subject: Re: Oracle specific jdbc and J2EE application server You can do the same in OC4J 10.1.3 DP3 (see: http://www.oracle.com/technology/tech/java/oc4j/index.html) Best, Manfred Back to top kimtiede@gmail.com Guest Posted: Thu May 12, 2005 1:09 pm    Post subject: Re: Oracle specific jdbc and J2EE application server Manfred Rosenboom wrote: Quote: You can do the same in OC4J 10.1.3 DP3 (see: http://www.oracle.com/technology/tech/java/oc4j/index.html) Best, Manfred Thanks for your reply! Yeah - I can see that in the manual: <quote> Using Oracle JDBC Extensions To use Oracle JDBC extensions, cast the returned connection to oracle.jdbc.OracleConnection, as follows: Context ic = new InitialContext(); DataSource ds = (DataSource) ic.lookup("jdbc/OracleCMTDS1"); oracle.jdbc.OracleConnection conn = (oracle.jdbc.OracleConnection) ds.getConnection(); You can use any of the Oracle extensions on the returned connection, conn. // you can create oracle.jdbc.* objects using this connection oracle.jdbc.Statement orclStmt = (oracle.jdbc.OracleStatement)conn.createStatement(); // assume table is varray_table oracle.jdbc.OracleResultSet rs = orclStmt.executeQuery("SELECT * FROM " + tableName); while (rs.next()) { oracle.sql.ARRAY array = rs.getARRAY(1); ... } </quote> But what if I'm not using an application server from Oracle (which I'm not Other application servers will give me a classcast exception. Thanks in advance! Kim Back to top Joe Weinstein Guest Posted: Thu May 12, 2005 3:01 pm    Post subject: Re: Oracle specific jdbc and J2EE application server [email]kimtiede (AT) gmail (DOT) com[/email] wrote: Quote: Hi there, We need to use the Oracle specific jdbc features such as mapping an Java object to a Oracle Type and for that reason we need to cast the connection and statements returned from the jndi datasource to Oracle extensions, such as the code below: CallableStatement cstmt = conn.prepareCall(sql); OracleCallableStatement ocs = (OracleCallableStatement)cstmt; ocs.setORAData(1, gepjList); ocs.setInt(2, afsenderID); ocs.executeUpdate(); Unfortunately it seems that J2EE application servers seems to wrap the inner connection to the Oracle database and we get a classcast exception. The http://jakarta.apache.org/commons/dbcp framework allows you to setAccessToUnderlyingConnectionAllowed to true and thereby getting the innermost delegate. Is there a similar feature on a J2EE application server or is there another workaround? Hi. Oracle made the mistake of delivering their extra methods without providing an Interface, so you have to cast to a concrete class to access the methods. If they had defined OracleCallableStatement as an Interface, then wrappers could also implement the Interface, and simply pass your calls back and forth to the Oracle object. Some application servers (ours at least) provide workarounds: 1 - They implement their own interface, containing those extra methods, so your code can cast to this interface to make your calls. 2 - They offer App-server methods that will provide you with direct access to the wrapped oracle object for your use as above. There are dangers and limitations to both of these options. Application servers wrap such objects for many good reasons. Typically these objects come from a pooled JDBC connection, and the application server needs to be able to guarantee that no two threads/users will be operating on a given pooled connection at the same time. With wrappers, the app server can enforce this, but once the user code had direct references to the connection or any subordinate object (from which they can get the connection reference), we cannot prevent the reference being saved and shared inappropriately. However, this feature is sometimes necessary anyway because some of Oracle's extra JDBC functions take java.sql.Connections as arguments, (that's what the signature says, but it's false advertising). Inside the Oracle code however, they *also* cast the java.sql.Connection they get to concrete oracle objects, so the oracle code eventually fails with a classcast exception unless it has been given a naked oracle object as input. Therefore, our methods for obtaining the naked references also trigger a default safety behavior, that as soon as your current thread is finished doing JDBC, the underlying pool connection is closed and replaced. This is safe, but the replacement of connections removes the speed benefit of pools, so we also provide a configurable setting that allows you to tell us to trust your code, and not to replace exposed pool connections. You would set this option if/when you were sure your threads wouldn't do any harmful sharing. Then you'd get the best of both worlds. We also provide JDBC proxies for use in external clients of the application server, acting like a type-3 driver. In this situation the real non-serializable Oracle object is in the remote server JVM, so it cannot be ever delivered to the external client, but the RMI proxy objects do implement as many of the oracle methods as can be done in a proxy mode. Joe Weinstein at BEA Quote: Thanks in advance Cheers Kim Back to top kimtiede@gmail.com Guest Posted: Fri May 13, 2005 7:40 am    Post subject: Re: Oracle specific jdbc and J2EE application server Hi Joe, Thanks for your reply - great to have an answer in such detail :-) Joe Weinstein wrote: Quote: [email]kimtiede (AT) gmail (DOT) com[/email] wrote: Hi. Oracle made the mistake of delivering their extra methods without providing an Interface, so you have to cast to a concrete class to access the methods. If they had defined OracleCallableStatement as an Interface, then wrappers could also implement the Interface, and simply pass your calls back and forth to the Oracle object. Yeah - that's true... That would have been nice... Unfortunately our project is locked on IBM WS since the customer has experiences with this application server. As far as I can see the WS does not have the same workaround but I havent made a deep investigation. I think we will try to contact IBM and hear what they have to say. Once again thanks for your answer! Kim Back to top Mark Matthews Guest Posted: Fri May 13, 2005 2:50 pm    Post subject: Re: Oracle specific jdbc and J2EE application server [email]kimtiede (AT) gmail (DOT) com[/email] wrote: Quote: Hi Joe, Thanks for your reply - great to have an answer in such detail :-) Joe Weinstein wrote: [email]kimtiede (AT) gmail (DOT) com[/email] wrote: Hi. Oracle made the mistake of delivering their extra methods without providing an Interface, so you have to cast to a concrete class to access the methods. If they had defined OracleCallableStatement as an Interface, then wrappers could also implement the Interface, and simply pass your calls back and forth to the Oracle object. Yeah - that's true... That would have been nice... Unfortunately our project is locked on IBM WS since the customer has experiences with this application server. As far as I can see the WS does not have the same workaround but I havent made a deep investigation. I think we will try to contact IBM and hear what they have to say. Once again thanks for your answer! Kim Kim, WebSphere has the following way of accomplishing what you ask for: http://publib.boulder.ibm.com/infocenter/ws51help/topic/com.ibm.websphere.base.doc/info/aes/ae/rdat_levport.html?resultof=%22%77%73%63%61%6c%6c%68%65%6c%70%65%72%22%20%22%77%73%63%61%6c%6c%68%65%6c%70%22%20 (look for WSCallHelper). One of the things the JDBC-4.0 experts' group is looking to do is to standardize this functionality. Unfortunately that won't be available until Java-6.0 (Mustang) is released, so the work won't help you _today_. If you plan on supporting multiple application servers with your product, I'd try and isolate this code in some pluggable layer so you won't have to re-write it when JDBC-4.0 comes out, and at the same time have the option of supporting other vendors' products. Regards, -Mark -- Mark Matthews MySQL AB, Software Development Manager - Connectivity www.mysql.com Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         AppletTalk.com Forum Index -> Java and Databases All times are GMT Page 1 of 1   Jump to: Select a forum Java Newsgroups----------------Java DiscussionsWeb-based java games comp.lang.java 3D Graphics API's for Java Java: Support and criticism Java System Announcements comp.lang.java.api JavaBeans Java and CORBA Java and Databases comp.lang.java.developer Java GUI Toolkits Java Help comp.lang.java.javascript JVM, native methods and hardware comp.lang.java.misc Java Language Programming Security and Java comp.lang.java.setup Java Software Tools comp.lang.java.tech ibm.software.java.linux  Non-English Java Newsgroups----------------Java Language (German)Language Java (Français)Java (Italian)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.