Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Balaji

Greenhorn
+ Follow
since Dec 02, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Balaji

I have a doubt regarding usage of ServiceLocator Design pattern. This pattern's intention is to remove the expense of Remote Lookups of EJBHome Interfaces, Connection Factory, Queue Names, Datasources by caching them in some datastructure and reusing them again, whenever required. IBM suggests and has a short paper on it website as well.
My concern is will this caching be a cause of concern in a Clustered Environment. For e.g. if we cache EJBHome for instance, and that particular server
in the cluster goes down, then the application will fail because it will keep getting the same EJBHome pointing to that appserver instance in that cluster which is down. Is there any way that Websphere provides to eradicate this problem ? Does Websphere allow some kind of configuration to remove this. There is something known as Clusterwide JNDI tree available in JBOSS. Do we have something like that in Websphere.
"JBoss has a cluster-wide JNDI tree that is replicated across the entire cluster. It requires no additional configuration and boots up with a cluster-enabled JBoss configuration. Remote JBoss JNDI clients can also implicitly use multicast to discover the JNDI tree"

If we have something like this in Websphere, we can use the ServiceLocator Design pattern without any issues in a Websphere Environment. This can be added as a good J2EE practice in my list.
15 years ago
I have a doubt regarding usage of ServiceLocator Design pattern. This pattern's intention is to remove the expense of Remote Lookups of EJBHome Interfaces, Connection Factory, Queue Names, Datasources by caching them in some datastructure and reusing them again, whenever required. IBM suggests and has a short paper on it website as well.
My concern is will this caching be a cause of concern in a Clustered Environment. For e.g. if we cache EJBHome for instance, and that particular server
in the cluster goes down, then the application will fail because it will keep getting the same EJBHome pointing to that appserver instance in that cluster which is down. Is there any way that Websphere provides to eradicate this problem ? Does Websphere allow some kind of configuration to remove this. There is something known as Clusterwide JNDI tree available in JBOSS. Do we have something like that in Websphere.
"JBoss has a cluster-wide JNDI tree that is replicated across the entire cluster. It requires no additional configuration and boots up with a cluster-enabled JBoss configuration. Remote JBoss JNDI clients can also implicitly use multicast to discover the JNDI tree"

If we have something like this in Websphere, we can use the ServiceLocator Design pattern without any issues in a Websphere Environment. This can be added as a good J2EE practice in my list.
15 years ago
Hi ,
Can anyone tell me about the part-2 of the SCEA exam. Is it a multiple choice exam or we have to give some kind of completed assignment to SUN...

thanks,
Hi,
You have set the classpath only in the build.
Have you set the classpath for the driver to get the Classes at runtime.
If you are writing a plain java application, you need to add these jar files in the RUN option
or if you are running these in a server (Test Server) you need to create a datasource with the variable set to this driver.
16 years ago
SCJP 1.4 Passed with 88%

-Balaji Iyer
16 years ago