Do Not Use Commas For Multi-Source JNDI

Here’s a bit of fun with WebLogic JDBC configurations.  I ran into this issue after reading that p13nDataSource and  cgDataSource-NonXA should not be configured as multi-source. There were  some issues changing them to use the basic JDBC connection string and  when rolling back to the bad configuration the server went “Boom”.  Since one purpose behind this blog is to share lessons learned, I just had to post this.

If you write your descriptors manually (as opposed to generating them using the WLS console) and put a comma-separated list of JNDI addresses like this:

<jdbc-data-source-params>
  <jndi-name>weblogic.jdbc.jts.commercePool,
	contentDataSource,
	contentVersioningDataSource,
	portalFrameworkPool</jndi-name>
  <algorithm-type>Load-Balancing</algorithm-type>
  <data-source-list>portalDataSource-rac0,
	portalDataSource-rac1</data-source-list>
  <failover-request-if-busy>false</failover-request-if-busy>
</jdbc-data-source-params>

so long as the first address resolves, it will still work. Sort of.  If you call this connection to do an update, only one node of the RAC instance is updated. Other wonderful side-effects include the server refusing to start sometimes.

The proper way to list the JNDI sources is one per node, like this:

<jdbc-data-source-params>
	<jndi-name>weblogic.jdbc.jts.commercePool</jndi-name>
	<jndi-name>contentDataSource</jndi-name>
	<jndi-name>contentVersioningDataSource</jndi-name>
	<jndi-name>portalFrameworkPool</jndi-name>
	<algorithm-type>Load-Balancing</algorithm-type>
	<data-source-list>portalDataSource-rac0,
			portalDataSource-rac1,
			portalDataSource-rac2
	</data-source-list>
	<failover-request-if-busy>false</failover-request-if-busy>
</jdbc-data-source-params>

 

(Props to Sandeep Seshan for locating the root cause)

If you found this interesting, please share.

© Scott S. Nelson

Banishing Browser Caching in WebLogic Portal 10.3.2

I had a problem the other day where a user that was logged out still had their name showing on the screen. I thought the session wasn’t being invalidated, but it was actually a case of the browser caching the page. Digging around, I found a solution that, when added to a backing file for the desktop to run during pre-render did the trick:

import com.bea.netuix.servlets.controls.content.backing
               .JspBacking;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class NoCacheBacking implements JspBacking

{
   public void dispose(){}
   public boolean handlePostbackData(HttpServletRequest request,
      HttpServletResponse response)
   {

      return false;
   }

   public void init(HttpServletRequest request,
      HttpServletResponse response){}
   public boolean preRender(HttpServletRequest request,
      HttpServletResponse response)
   {
      response.setHeader("Cache-Control" ,
                   "no-cache, must-revalidate");
      response.setHeader("Pragma", "no-cache");
      response.setHeader("Cache-Control","no-store");
      response.setDateHeader ("Expires", 0);

      return false;
   }
}
If you found this interesting, please share.

© Scott S. Nelson