I would like to know what is the best solution to handle “java.lang.NullPointerException”. I have several services that connects to the same database that calls store procedures on the database and closes it after completion. I have a gut feeling that one service completes first and closes out the database connection and causes the exception for the other transaction (at com.wm.app.b2b.server.JDBCConnection.call(Unknown Source)). I was curious if anyone has a logical solution to handle this type of issue. All my services are executing asynchronously.

In pure Java terms the best solution to handle NullPointerException is never have one. Any time you reference the object and reference is suspect to be null you need to check first for the null value and back out in case of one.
If you have services which share the database connection then maybe you need to re-think them the way that they don’t share connection or at least synchronize access to it.
HTH

Here’s more information of my sql database connection:

1. connect (hardcode %dbAlias and drop it from pipeline out)
2. startTransaction (uses $dbConnection object produce from connect object)
3. call (stored procedure, uses $dbConnection object)
4. Loop
5. commit (uses $dbConnection object)
6. close (uses $dbConnection object)

In my catch block:

1. getLastError
2. rollback (hardcode $dbAlias and drop it from pipeline out)
3. close (uses $dbConnection object)

I have about 4 services that is define this way to connect to the same database. During the loop, I’m getting the nullpointerexception error because I belive $dbConnection is close somehow.

Among your 6 steps try to isolate the step where the exception is thrown.
For example, keep utility variable and change it with the progress of the flow. Then check its value in the pipeline saved in the lastError.
Or just log the steps… whatever works for you.
You may also want to drop $dbConnection after each close.
HTH

P.S. Sorry, I am leaving for vacation and may not have access to internet for some time - I hope your problem will be gone by the time I am back

I was able to resolve this error in the past by

a) making sure that the watt.server.db.blocktimeout, watt.server.db.connectionCache, watt.server.db.maintainminimum and other connection level attributes have appropriate values

b) adding appropriate JDBC properties in the WmDB alias.

c) using a variable name other than $dbConnection in the pipeline (map $dbConnection to $yourConnection back and forth and drop the $dbConnection after the the pub.db.<xyz> service).

d) changing the session timeout (in the IS). This is especially useful if your service is being called by TN asynchronously

e) if scheduler is calling your service, dont invoke the service directly. Use a java service that does a ‘context.invoke’ instead.

Hopefully this will help. I will start at “micro” level resolution techniques (like pipeline maintenance, checking the pipeline when this error happens) and move gradually to more “macro” resolution techniques (like database connection parameters, JDBC properties, server session timeout).

Thanks,
Uday.

Uday approach should work. I also consider using connection pooling of webMethods. This way you are not sharing connections and also you can maintain low number of connections open.

Cheers,
Mahmood

Nipun,

Are you using webMethods Suite or diff tool with java client?

Ravi,

I won’t recommend using sun.jdbc.odbc.JdbcOdbcDriver. Instead configure a JDBC Adapter connection using oracle.jdbc.pool.OracleConnectionPoolDataSource as DataSource class.

Good luck.

Pauly