-
1. Re: Getting DB connection from jboss pool via JNDI
peterj Jul 1, 2009 1:03 PM (in response to amayen)Remote clients do not have access to JNDI entries in the java: namespace, thus any items (such as data sources) that a remote client needs must be in the global namespace. Of course, once the name is moved out of the java: namespace, then even local clients need to look the name up in the global namespace.
(Please use the 'code' tag when posting XML text - otherwise the browser thinks the tags are html and tries to render them, making the post difficult to read.) -
2. Re: Getting DB connection from jboss pool via JNDI
amayen Jul 2, 2009 3:00 AM (in response to amayen)Ok, thanks for the answer.
What I'm still not 100 % sure is what the term remote client suggests.
Is a Tomcat that runs on the same physical machine but in another process than JBoss a 'remote' client?
And if this is so, how do you go about letting also JSP's and JSP Beans used in Tomcat profit from the JBoss connection pooling WITHOUT using the Antipattern of putting db resources in the global JNDI namespace with the use of<use-java-context>false</use-java-context>
?
That is my main concern, the application is functioning with that configuration but everywhere I read it is said you should not do that.
So which alternatives to that do I have? Is the only alternative to run the tomcat instance embedded in jboss?
And local clients are only clients that were spawned through the same java process which was used to start the jboss server?
Kind regards,
Anatol -
3. Re: Getting DB connection from jboss pool via JNDI
peterj Jul 2, 2009 11:26 AM (in response to amayen)Is a Tomcat that runs on the same physical machine but in another process than JBoss a 'remote' client?
Yes. Any Java app that runs in another java process (not the java process running JBoss AS) is a remote client. And app that runs within the same java process as JBoss AS is considered to be a local client.how do you go about letting also JSP's and JSP Beans used in Tomcat profit from the JBoss connection pooling WITHOUT using the Antipattern of putting db resources in the global JNDI namespace
You can't. I'm not exactly sure of why this was declared an anti-pattern, but I think it has more to do with the remote access to the datasource than to placing the datasource's name in the global JNDI area. Thus, even with the datasource name in global JNDI, any local access to the datasource is not exhibiting the anti-pattern.Is the only alternative to run the tomcat instance embedded in jboss?
There is already a Tomcat instance embedded within JBoss AS. Though since 4.2.0 it is called JBoss Web which is based on Tomcat. -
4. Re: Getting DB connection from jboss pool via JNDI
amayen Jul 4, 2009 6:01 AM (in response to amayen)Ok, thanks for clarifying Peter!
The reason I believe that this is an anti-pattern comes from reading some sources on the internet like the following:
http://www.jboss.org/community/wiki/ConfigDataSources
In clause "Configuring a DataSource for remote usage" it is said that:This results in the DataSource being bound under the JNDI name "GenericDS" instead of the default of "java:/GenericDS" which restricts the lookup to the same VM as the jboss server.
Note: JBoss does not recommend using this feature on a production environment. It requires accessing a connection pool remotely and this is an anti-pattern as connections are not serializable. Besides, transaction propagation is not supported and it could lead to connection leaks if the remote clients are unreliable (i.e crashes, network failure). If you do need to access a datasource remotely, JBoss recommends accessing it via a remote session bean facade.
So I'm still a little bit in the dark of why the project I'm working on now, seemed to be working without use-java-context and without using remote session bean facades as indicated in the qoute. Its a little mistery till now to me.
Is having Tomcat and JBoss in a separate process so uncommon?
I'm considering testing to use the embedded tomcat, maybe that helps.
Kind regards, Anatol