RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Yep, the very same. He reads the ejb-interest list and frequently posts very informative missives there. In fact, an excellent education can be obtained simply by searching the archives for his name. Seriously. Jeff -Original Message- From: Kemp Randy-W18971 Sent: Thu 2/8/2001 6:05 AM To: Orion-Interest Cc: Subject: RE: Orion-console in 1.4.7 supports DataSource properly... now what!!! Is this the same Richard who heads www.openejb.org? Their site mentions: OpenEJB is the brainchild of Richard Monson-Haefel, author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000). The core development team for OpenEJB is Mr. Monson-Haefel and David Blevins. -Original Message- From: Jeff Schnitzer [ mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 8:22 PM To: Orion-Interest Subject: RE: Orion-console in 1.4.7 supports DataSource properly... now what!!! I posted this question to the ejb-interest list, and got back the two attached responses. The one from Richard Monson-Haefal is most interesting, because it pretty much confirms that WebLogic uses a JDBC proxy. I agree, being able to communicate with the database behind a firewall means there must be some sort of proxy implemented by Orion. It's not just a simple question of putting an RMI proxy on the Connection (and Statement, DatabaseMetaData, etc), though... you certainly wouldn't want the ResultSet to be remoted otherwise you would suffer worse performance than plain EJB calls. And if you returned the ResultSet as a single object you would have serious problems with large queries. Interesting. Why again aren't you implementing this logic server-side? :-) Jeff -Original Message- From: Daniel Cardin [ mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 5:37 AM To: Orion-Interest Subject: RE: Orion-console in 1.4.7 supports DataSource properly... now what!!! Jeff, Are you sure that the JDBC driver isn't finding its way into the classpath? Did you try the console remotely from a machine that you know doesn't have the JDBC driver? Honestly, I haven't. But I still fail to see why it would be needed. If the data access was done using the "real" JDBC driver on the client, the connection to the database would have to be opened there... It's not the case. Running tests at home allowed me to prove that the Connection must be proxied through Orion because my client could not see the SQL server. The only conclusion is that Orion opens a connection locally, pools it, and on demand gives a proxy to it allowing all database access to go through the App Server... You may already know this, but just in case: Almost all of the orion tools (including orionconsole.jar) are simply empty jar files with a manifest that sets the Class-Path to include orion.jar and defines the appropriate Main-Class. You're still loading the orion.jar classes, potentially activating whatever classloader loads jars (especially the JDBC driver) out of the lib directory. Did you take this into account in your tests? I know about the way orionconsole works, thanks :) I've actually spent quite some time analysing com.evermind.gui.server and com.evermind.server to figure out exactly what's going on. So far, I believe DataSource access goes through another JNDI bound object the ApplicationAdministrator. I still have to test that avenue fully. We now have four different theories about how application-client JDBC works in app servers: 1) Database-specific JDBC driver gets packaged with the application client and loaded into the client VM. 2) Database-specific JDBC driver gets http-classloaded into the client VM. 3) Serialized classes come from JNDI. Actually, I think this is just another way of saying #2, because java RMI uses http classloading to get the class definitions to a new client. 4) App server provides a JDBC proxy which implements a proprietary wire protocol (or at least RMI "object protocol") to communicate with the server. Note that this is not just simply a
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Allen,
You are right... the lookup from within any EJB works flawlessly. I am
trying to get it to work on the client side.
See my other reply for more info...
Thanks for your comment,
Daniel
-Message d'origine-
De : Allen Fogleson [mailto:[EMAIL PROTECTED]]
Envoy : 6 fvrier, 2001 21:30
: Orion-Interest
Objet : RE: Orion-console in 1.4.7 supports DataSource properly... now
what!!!
Daniel;
As far as I can tell the DS lookup works in 1.4.7 I have an app that
does
many lookups and I just ran it unchanged from 1.4.5 to 1.4.7. Now
Granted I
am in orion so I just have to do a...
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/myDS");
So maybe it might not work with the initialApplicationContext??
(although
the console belies that)
Al
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Cardin
Sent: Tuesday, February 06, 2001 4:17 PM
To: Orion-Interest
Subject: Orion-console in 1.4.7 supports DataSource properly... now
what!!!
Hi everyone!
I'm progressing... Orion 1.4.7 has support for DataSources in the
orion-console application.
If you select a DataSource, you will see a new panel allowing you to
enter SQL commands that will
be sent directly to the database through the DataSource + connection.
it WORKS in the console. So this implies that :
1. the concept is valid : you don't need to use a driver instance on the
client side, contrary to what
some of you stated. No JDBC download, nothing... just a proxy
instance implementing the Connection interface
2. the client doesn't need to see the database server on the same
network
3. my datasources are configured PROPERLY on the server side... (I was
always doubting that
but normal DS, pooled DS, EJB DS etc. all work from my client
(actually only XA won't work now))
SO: since I get perfect access through the console, either
a) I can't do a JNDI lookup! (I doubt that)
b) the DataSource lookup is not working (yet) in 1.4.7
c) OrionConsole uses another method than a simple lookup to get the
DataSource object.
Please everyone, realize this is important for performance issues and
let's try to make it work!
Thanks for your help
Daniel
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Jeff, Are you sure that the JDBC driver isn't finding its way into the classpath? Did you try the console remotely from a machine that you know doesn't have the JDBC driver? Honestly, I haven't. But I still fail to see why it would be needed. If the data access was done using the "real" JDBC driver on the client, the connection to the database would have to be opened there... It's not the case. Running tests at home allowed me to prove that the Connection must be proxied through Orion because my client could not see the SQL server. The only conclusion is that Orion opens a connection locally, pools it, and on demand gives a proxy to it allowing all database access to go through the App Server... You may already know this, but just in case: Almost all of the orion tools (including orionconsole.jar) are simply empty jar files with a manifest that sets the Class-Path to include orion.jar and defines the appropriate Main-Class. You're still loading the orion.jar classes, potentially activating whatever classloader loads jars (especially the JDBC driver) out of the lib directory. Did you take this into account in your tests? I know about the way orionconsole works, thanks :) I've actually spent quite some time analysing com.evermind.gui.server and com.evermind.server to figure out exactly what's going on. So far, I believe DataSource access goes through another JNDI bound object the ApplicationAdministrator. I still have to test that avenue fully. We now have four different theories about how application-client JDBC works in app servers: 1) Database-specific JDBC driver gets packaged with the application client and loaded into the client VM. 2) Database-specific JDBC driver gets http-classloaded into the client VM. 3) Serialized classes come from JNDI. Actually, I think this is just another way of saying #2, because java RMI uses http classloading to get the class definitions to a new client. 4) App server provides a JDBC proxy which implements a proprietary wire protocol (or at least RMI "object protocol") to communicate with the server. Note that this is not just simply a matter of remoting the implementation of the Connection interface; you would have to remote the implementations of ResultSet, Statement, and any other interfaces associated with JDBC. And you have to be pretty smart about how you do it, otherwise it's going to perform a lot worse than EJB methods. I tend so far to go for 4, just because it is impossible that my client running from home had access to the server. No direct TCP/IP route from my subnet to the company's 192.168.1.111/24 No way around that limitation :) My understanding... please all feel free to add to this, especially Orion's developpers !!! A DataSource is a mechanism used encapsulate access to JDBC connections. Orion manages Connections with the ConnectionDataSource objects. In "theory", a client uses JNDI to lookup the DataSource object, gets an RMI proxy, and retrieves a Connection object. the way I see it, the DataSource implementation on the server side HAS to return a proxy to the Connection, which only resides on the server. I don't see any other way around that explains why I could use the console from home and still get to the data. Now, I think that the current DataSource lookup does not work as I understand it should. Maybe I'm not proceeding properly. But now that I have seen it work in the console, I will not stop until it works in my client application! :) Does anyone out there *know* what Orion does? Anyone? :) Daniel -Original Message- From: Daniel Cardin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 1:17 PM To: Orion-Interest Subject: Orion-console in 1.4.7 supports DataSource properly... now what!!! Hi everyone! I'm progressing... Orion 1.4.7 has support for DataSources in the orion-console application. If you select a DataSource, you will see a new panel allowing you to enter SQL commands that will be sent directly to the database through the DataSource + connection. it WORKS in the console. So this implies that : 1. the concept is valid : you don't need to use a driver instance on the client side, contrary to what some of you stated. No JDBC download, nothing... just a proxy instance implementing the Connection interface 2. the client doesn't need to see the database server on the same network 3. my datasources are configured PROPERLY on the server side... (I was always doubting that but normal DS, pooled DS, EJB DS etc. all work from my client (actually only XA won't work now)) SO: since I get perfect access through the console, either a) I can't do a JNDI lookup! (I doubt that) b) the DataSource lookup is not working (yet) in 1.4.7 c) OrionConsole uses another method than a simple lookup to get the DataSource object. Please everyone, realize this is important for performance issues and let's try to make it work! Thanks for your help Daniel
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
I posted this question to the ejb-interest list, and got back the two attached responses. The one from Richard Monson-Haefal is most interesting, because it pretty much confirms that WebLogic uses a JDBC proxy. I agree, being able to communicate with the database behind a firewall means there must be some sort of proxy implemented by Orion. It's not just a simple question of putting an RMI proxy on the Connection (and Statement, DatabaseMetaData, etc), though... you certainly wouldn't want the ResultSet to be remoted otherwise you would suffer worse performance than plain EJB calls. And if you returned the ResultSet as a single object you would have serious problems with large queries. Interesting. Why again aren't you implementing this logic server-side? :-) Jeff -Original Message- From: Daniel Cardin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 5:37 AM To: Orion-Interest Subject: RE: Orion-console in 1.4.7 supports DataSource properly... now what!!! Jeff, Are you sure that the JDBC driver isn't finding its way into the classpath? Did you try the console remotely from a machine that you know doesn't have the JDBC driver? Honestly, I haven't. But I still fail to see why it would be needed. If the data access was done using the "real" JDBC driver on the client, the connection to the database would have to be opened there... It's not the case. Running tests at home allowed me to prove that the Connection must be proxied through Orion because my client could not see the SQL server. The only conclusion is that Orion opens a connection locally, pools it, and on demand gives a proxy to it allowing all database access to go through the App Server... You may already know this, but just in case: Almost all of the orion tools (including orionconsole.jar) are simply empty jar files with a manifest that sets the Class-Path to include orion.jar and defines the appropriate Main-Class. You're still loading the orion.jar classes, potentially activating whatever classloader loads jars (especially the JDBC driver) out of the lib directory. Did you take this into account in your tests? I know about the way orionconsole works, thanks :) I've actually spent quite some time analysing com.evermind.gui.server and com.evermind.server to figure out exactly what's going on. So far, I believe DataSource access goes through another JNDI bound object the ApplicationAdministrator. I still have to test that avenue fully. We now have four different theories about how application-client JDBC works in app servers: 1) Database-specific JDBC driver gets packaged with the application client and loaded into the client VM. 2) Database-specific JDBC driver gets http-classloaded into the client VM. 3) Serialized classes come from JNDI. Actually, I think this is just another way of saying #2, because java RMI uses http classloading to get the class definitions to a new client. 4) App server provides a JDBC proxy which implements a proprietary wire protocol (or at least RMI "object protocol") to communicate with the server. Note that this is not just simply a matter of remoting the implementation of the Connection interface; you would have to remote the implementations of ResultSet, Statement, and any other interfaces associated with JDBC. And you have to be pretty smart about how you do it, otherwise it's going to perform a lot worse than EJB methods. I tend so far to go for 4, just because it is impossible that my client running from home had access to the server. No direct TCP/IP route from my subnet to the company's 192.168.1.111/24 No way around that limitation :) My understanding... please all feel free to add to this, especially Orion's developpers !!! A DataSource is a mechanism used encapsulate access to JDBC connections. Orion manages Connections with the ConnectionDataSource objects. In "theory", a client uses JNDI to lookup the DataSource object, gets an RMI proxy, and retrieves a Connection object. the way I see it, the DataSource implementation on the server side HAS to return a proxy to the Connection, which only resides on the server. I don't see any other way around that explains why I could use the console from home and still get to the data. Now, I think that the current DataSource lookup does not work as I understand it should. Maybe I'm not proceeding properly. But now that I have seen it work in the console, I will not stop until it works in my client application! :) Does anyone out there *know* what Orion does? Anyone? :) Daniel -Original Message- From: Daniel Cardin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 1:17 PM To: Orion-Interest Subject: Orion-console in 1.4.7 supports DataSource properly... now what!!! Hi everyone! I'm progressing... Orion 1.4.7 has support for DataSources in the orion-console application. If you select a DataSource, you will see a new panel allo
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Are you sure that the JDBC driver isn't finding its way into the classpath? Did you try the console remotely from a machine that you know doesn't have the JDBC driver? You may already know this, but just in case: Almost all of the orion tools (including orionconsole.jar) are simply empty jar files with a manifest that sets the Class-Path to include orion.jar and defines the appropriate Main-Class. You're still loading the orion.jar classes, potentially activating whatever classloader loads jars (especially the JDBC driver) out of the lib directory. Did you take this into account in your tests? We now have four different theories about how application-client JDBC works in app servers: 1) Database-specific JDBC driver gets packaged with the application client and loaded into the client VM. 2) Database-specific JDBC driver gets http-classloaded into the client VM. 3) Serialized classes come from JNDI. Actually, I think this is just another way of saying #2, because java RMI uses http classloading to get the class definitions to a new client. 4) App server provides a JDBC proxy which implements a proprietary wire protocol (or at least RMI "object protocol") to communicate with the server. Note that this is not just simply a matter of remoting the implementation of the Connection interface; you would have to remote the implementations of ResultSet, Statement, and any other interfaces associated with JDBC. And you have to be pretty smart about how you do it, otherwise it's going to perform a lot worse than EJB methods. Does anyone out there *know* what Orion does? Jeff -Original Message- From: Daniel Cardin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 1:17 PM To: Orion-Interest Subject: Orion-console in 1.4.7 supports DataSource properly... now what!!! Hi everyone! I'm progressing... Orion 1.4.7 has support for DataSources in the orion-console application. If you select a DataSource, you will see a new panel allowing you to enter SQL commands that will be sent directly to the database through the DataSource + connection. it WORKS in the console. So this implies that : 1. the concept is valid : you don't need to use a driver instance on the client side, contrary to what some of you stated. No JDBC download, nothing... just a proxy instance implementing the Connection interface 2. the client doesn't need to see the database server on the same network 3. my datasources are configured PROPERLY on the server side... (I was always doubting that but normal DS, pooled DS, EJB DS etc. all work from my client (actually only XA won't work now)) SO: since I get perfect access through the console, either a) I can't do a JNDI lookup! (I doubt that) b) the DataSource lookup is not working (yet) in 1.4.7 c) OrionConsole uses another method than a simple lookup to get the DataSource object. Please everyone, realize this is important for performance issues and let's try to make it work! Thanks for your help Daniel
RE: Orion-console in 1.4.7 supports DataSource properly... now what!!!
Daniel;
As far as I can tell the DS lookup works in 1.4.7 I have an app that does
many lookups and I just ran it unchanged from 1.4.5 to 1.4.7. Now Granted I
am in orion so I just have to do a...
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/myDS");
So maybe it might not work with the initialApplicationContext?? (although
the console belies that)
Al
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Cardin
Sent: Tuesday, February 06, 2001 4:17 PM
To: Orion-Interest
Subject: Orion-console in 1.4.7 supports DataSource properly... now
what!!!
Hi everyone!
I'm progressing... Orion 1.4.7 has support for DataSources in the
orion-console application.
If you select a DataSource, you will see a new panel allowing you to
enter SQL commands that will
be sent directly to the database through the DataSource + connection.
it WORKS in the console. So this implies that :
1. the concept is valid : you don't need to use a driver instance on the
client side, contrary to what
some of you stated. No JDBC download, nothing... just a proxy
instance implementing the Connection interface
2. the client doesn't need to see the database server on the same
network
3. my datasources are configured PROPERLY on the server side... (I was
always doubting that
but normal DS, pooled DS, EJB DS etc. all work from my client
(actually only XA won't work now))
SO: since I get perfect access through the console, either
a) I can't do a JNDI lookup! (I doubt that)
b) the DataSource lookup is not working (yet) in 1.4.7
c) OrionConsole uses another method than a simple lookup to get the
DataSource object.
Please everyone, realize this is important for performance issues and
let's try to make it work!
Thanks for your help
Daniel
