Problem with WrappedConnection

[eddie07]

Hi,

I am using WrappedConnection for database access (oracle) in a stateful session bean.
When jboss tries to passivate this bean I get the following error message:
-----
javax.ejb.EJBException: Could not passivate; failed to save state; CausedByException is:
org.jboss.resource.adapter.jdbc.WrappedConnection
-----
And finally, when I try to use this session bean again with a servlet the browser displays a "HTTP Status 500", jboss shows the following error:
-----
ERROR [Engine] StandardWrapperValve[STN]: Servlet.service() for servlet STN threw exception
java.lang.NullPointerException
-----

Is there a way to solve this problem?

Eddie

[eddie07]

This is the corresponding part of my source code (in ejbCreate because I don't need the connection later):

ds = (javax.sql.DataSource)initContext.lookup(dsName);
conn = ds.getConnection();

Calling another function (part of the same bean) which does this:
WrappedConnection wc = (WrappedConnection)conn;
Connection c = wc.getUnderlyingConnection();
// using connection
wc.close();
wc = null;
c = null;

Return to ejbCreate:

ds = null;

[davidjencks]

where is the conn = null; line.

Generally I recommend NOT having an instance variable for a connection but obtaining it only when needed and closing it immediately.

[eddie07]

> where is the conn = null; line.

ups, this was the problem.
Nevertheless I still have the problem that the bean can't be passivated, now because of an open socket. I know it's not a good idea to do this but I must have/keep an open socket. I wouldn't care if passivate does not work but after trying to use the bean later I get another exception that it can't be activated.
What would be a better way to handle this? Either not to allow jboss to passivate it (how?) or handling the connection somewhere else (where)? Connection pooling is not possible because exactly this (telnet) connection must be used.

Thanks again for your help,
Eddie

[davidjencks]

Having a socket in an ejb is a pretty bad idea IMO, and you are finding out some of the reasons why.

How about using an mbean to manage the socket? It's a singleton and doesn't get passivated.