Out of the Gate Productions

Check out my new vc venture.


Posted in Uncategorized | Tagged , , | Leave a comment


Thanks a lot Twitter. . .


Posted in Twitter | Tagged , , , , | Leave a comment

Oracle Connection Pools in Tomcat Part 3 – Combating Invalid and Stale Connections

In our Oracle Connection Pool series we have identified how to implement and basic configurations. Before we examine more higher degree advanced configurations, it is important to note one of the drawbacks of the Oracle Connection Pool.

It has come to my attention that there is a fatal flaw within the Oracle Connection Pool architecture and this has been noted in many help forums around the internet and world wide web. There are many complaints regarding Invalid and Stale Connections when utilizing the Oracle Connection Pool for one’s database connection cache needs.

Here is the error that I see when my app crashes:

<org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Invalid or Stale Connection found in the Connection Cache>

This has indeed become a thorn in my side, since it is mandatory that I use the Oracle Connection Pool in order to let my app utilize Oracle only functionality. That is to say, I just can’t throw away my relational db and replace it with some NoSQL MongoDB type of thing. Rather, indeed I am stuck with the Oracle Connection Pool, so what can one do to combat these Invalid and Stale Connections that are persisting behind the scenes of my app?

First, let’s check the configurations and see if we can do anything there. As noted in Part 2 of this series, there are certain connectionCacheProperties that Oracle has put forth so us architects and developers may tweak the connection pool to act accordingly depending upon our business requirements.

Checking out some Oracle documentation regarding the Oracle Connection Pool and associated Connection Cache Properties, it is fair to say that Oracle accounted for the existence of Invalid and/or Stale Connections.

An important property to note is: ValidateConnection

Setting ValidateConnection to true causes the connection cache to test every connection it retrieves against the underlying database. If a valid connection cannot be retrieved, then an exception is thrown.

Default: false

Great! Now add this to your database connection information along with some other properties to govern your connection pool wisely.

<Resource auth="Container"
description="Oracle Datasource"
connectionCacheProperties="{MaxStatementsLimit=10, MinLimit=1, MaxLimit=200, ValidateConnection=true}"

Henceforth, Oracle should double check each connection and promptly exterminate any bogus connections that attempt to make it through to our app.

Has anyone had any success using the infamous ValidateConnection property? Does it do its job? We shall see in the next edition of Oracle Connection Pools in Tomcat.

Posted in Database, Oracle, Spring Framework, Tomcat | Tagged , , , , | 3 Comments

The star that shines twice as bright, burns for half as long.

Posted in Uncategorized | Leave a comment

Java Hosting for the 21st Century

I have been in the Java game for almost a decade and I have always been on the lookout for free or affordable java hosting. Back in the day when i was right out of school i found a lesser known site known as myjavaserver.com.

I was able to deploy my apps there in a test environment and see how it looked. I was even able to get a domain and forward traffic to myjavaserver.com and go live. Old school sites such as ginezproductions.org, edisupportforum.com, and blahblahblah.com were hosted there during my search for web glory days. Long since dead, those sites live on in my heart and mind.

Every once in a while I take a look for Java Hosting, yet it is never easy nor affordable. Like i’m gonna pay GoDaddy some $30 bucks a month for some stinkin’ JSPs only. F that! I want a Tomcat at my disposal. i want to throw some WARs up on the server and see the deployment logs in front of me. I want to taste the Servlet engine as it fires up and gets ready for some processing.

Finally, there seems to be an option out there. I was checking out some TechCrunch and they gave me a lead to a new Java Hosting environment. Jelastic, a U.S./Ukrainian/Russian provider of a cloud-based deployment platform for Java apps has unveiled a beta hosting service with two week trial period to check it out.

That’s good enough for me. I signed up and was brought immediately to a create environment page.

I chose a Tomcat 7, JDK 6, and grabbed a subdomain name. Easy as pie. Had to wait a few minutes while it created the server of my choice and Viola, I was now in a server view where I could deploy WARs and such.

FrozenGround just stuck in my head and I didn’t want to ponder on some test subdomain. Now I was able to deploy the test WAR package that was laid out for me.

I get to choose my context of course.

And then after a quick deployment, I get to open it in my browser.

Boom! The infamous Hello World is displayed. Nice!

TechCrunch filled me in on some other information regarding Jelastic.

“Jelastic, which competes with Heroku and Google App Engine, offers developers of Java applications a hosted platform based around standard software stacks, which it says helps avoid lock-ins and code changes. The company launched its public beta in October 2011, and since then has picked up over 15,000 unique users.

The product is available in the US through Servint, in Europe through dogado / HostEurope and Rusonyx in Russia.

Jelastic’s basic idea is to take a different approach to the hosting and deploying of Java apps: Normally, in order to host an application, one goes to, for example, Amazon Web Services, but configuring virtual machines manually takes time. This means developers have to install and maintain an operating system and application servers, instead of spending time on improving the core product.”

Seems pretty cool so I am going to get busy busting down some NetBeans and throwing together some Spring web apps to deploy to this bad boy. I am going to burn this mofo down the next 2 weeks and then check out how affordable a single Tomcat server is to maintain. My guess it will be alot less than GoDaddy’s JSP crock of a deal.

Posted in Java Server Deployment | 2 Comments

Standalone Tomcat Memory Increase

IDEs make it easy now a days to add a server and then increase memory in a user friendly GUI. But what if you are running a standalone Tomcat server that you have to startup from the command line? How do you increase the memory with only config files in the /bin directory at your disposal?

After some research I found out exactly how to do it and the Tomcat Manager GUI let me see that it was proof positive that my server was running with half a Gig under its belt.

First start up your Tomcat out of the box, configure and login to the manager app. Once you are there, Tomcat offers a number of links that provide server wide information.

Click on the Server Status link. On the page there will be some info regarding the JVM memory that is allocated towards this instance of Tomcat. The amounts will vary, yet out of the box take a look at the Free memory after deploying a single app. Total memory is whack too. A couple of deployments and re-deployments and you guessed it. The server hangs with a Perm Gen error and it’s time to restart the server. Bummer dude!

To increase some memory, let’s first look at the TOMCAT_HOME\bin\catalina.bat (catalina.sh for Linux) file. Open it up and a bit after the initial ho hum important license agreement you will find a note to any potential Tomcat/Catalina hackers. “Do not set the variables in this script. Instead put them into a script
setenv.bat (setenv.sh for Linux) in CATALINA_BASE/bin TOMCAT_HOME/bin to keep your customizations separate.”

Viola! The Apache crew has shown us where to put customizations to the Tomcat engine, so let’s do that.

  1. Create a setenv.bat (Windows) or setenv.sh (Linux) file.
  2. Place the file in the TOMCAT_HOME/bin directory
  3. Pop this line of configuration in the file for Windows
  4. set JAVA_OPTS=-server -XX:MaxPermSize=128m -Xms512m -Xmx512m -Xss256k
  5. Pop this line of configuration in the file for Linux
  6. export JAVA_OPTS=”-server -XX:MaxPermSize=128m -Xms512m -Xmx512m -Xss256k”
  7. Restart your Apache Tomcat Server.

Now, let’s check out our available memory from the Server Status page.

Now that’s what I’m talkin’ about. Some serious memory for a serious developer. Cast those Perm Gen errors into the abyss as you deploy multiple apps and web services on a single Tomcat server instance. Take that Perm Gen!

Posted in Apache, Tomcat | 2 Comments

Spring Framework Transaction Management

In our previous post we linked up a JDBC connection defined in our Tomcat context.xml file to the Spring Framework. The way the datasource was defined in Spring was as a bean.

<bean id="dataSource">
<property name="jndiName"><value>java:comp/env/jdbc/test</value></property>

In order to enable Transaction Management for our dataSource is to wrap it with Spring’s Transaction Manager bean.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource"><ref local="dataSource" /></property>

Next, one will have to reference this Transaction Manager wrapped dataSource in a Manager bean of one’s choosing that holds the JDBC SQL for your application.

For example, one should have an interface and then an implementation that does the actual JDBC work.

// the service interface that we want to make transactional
package foo.bar.dao;

public interface FooJdbcInterface {

Foo getFoo(String fooName);

void updateFoo(long fooId, String fooString);


// an implementation of the above interface

package foo.bar.dao;

public class FooJdbcImpl implements FooJdbcInterface {

public Foo getFoo(String fooName) {
String someString = (String) getJdbcTemplate().queryForObject("select somestring from sometable where somecolumn = ?", new Object[]{fooName}, String.class);

public void updateFoo(long fooId, String fooString) {

// update some column
getJdbcTemplate().update("update sometable set somecolumn = 'bar' where anothercolumn = ?", new Object[]{fooId});

// do some other query, yet if there is no result that comes back, there will be an Exception
String anotherString = (String) getJdbcTemplate().queryForObject("select somestring from sometable where somecolumn = ?", new Object[]{fooString}, String.class);

// do another update
getJdbcTemplate().update("update anothertable set somecolumn = 'foo' where anothercolumn = ?", new Object[]{fooId});
catch(Exception e){
log.error("there has been an error, rolling back...");



So, now we have a couple of methods in our JDBC class that will perform some JDBC operations (via Spring JdbcTemplate), when called by any what who Controller. The method that we are going to focus on is the updateFoo method. Basically, we want to ensure that all of the JDBC operations are performed as a whole and not on a 1 by 1 basis. For example, say our first update goes through “update sometable set somecolumn = ‘bar’ where anothercolumn = ?”, then there is a query “select somestring from sometable where somecolumn = ?” to get a value for the next update “update anothertable set somecolumn = ‘foo’ where anothercolumn = ?”.

What if the query to get the value for the second update fails? We then have a situation where only half of the updateFoo methods operations have succeeded and because of that there could be some down the line data issues that arise due to 1 update being committed to the database and the 2nd update not even being executed due to the fact that the select query failed to bring any results and an Exception was thrown.

Transaction Management will ensure that the updateFoo method will execute as an all or nothing operation. If the select query fails to bring any results, then the first update of the updateFoo method will be rolled back; therefore the data integrity of the database schema will be preserved.

To do this, one must use some AOP to tell Spring Transaction Management what to observe.

First, hook up the required Spring namespaces to your xml configuration file so that we can use the special tags we need to get Transaction Management monitoring working for our app.

<beans xmlns="http://www.springframework.org/schema/beans"
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

Now, that we have registered our tx and aop namespaces, let’s put those tags to work. Use the below tx tag configuration to tell our Spring Transaction Management to observe and monitor all “update” methods for the particular interface we want Transaction Management to work for.

<tx:advice id="txAdvice">
<tx:method name="update*" propagation="REQUIRED" isolation="READ_COMMITTED" rollback-for="Exception" />

Next, use AOP pointcuts to tell Spring Transaction Management which package and interface to watch.

<!-- ensure that the above transactional advice runs for any execution
of an operation defined by the FooJdbcInterface interface -->
<aop:pointcut id="fooOperation" expression="execution(* foo.bar.dao.FooJdbcInterface.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="fooOperation"/>

Now, any update methods of a class that implements foo.bar.dao.FooJdbcInterface will officially be using Spring Transaction Management.

There are also a couple extra jars that one needs besides the regular Spring entourage of jars to get Transaction Management to work. Basically, some libraries to get AOP rolling within your app.


With these configurations, one should be up and running with Spring Transaction Management. Make sure and use your DEBUG logging settings to see what Spring is doing in the background when you need to trouble shoot and make sure that Transaction Management is working for your app.

Cheers, Javaclaus

Posted in Spring Framework | 1 Comment