Migration show stopper: Sticky database connections ?

[dkoon]

We are migrating from Weblogic to JBoss 4.01 SP1. The DBMS is MS SQL 2000. We would have almost cutover it to production but we are blocked by a show stopper.

Our applicatin supports users from different companies. Each company has its separate datasource. The sign-in userid contains the name of the company, and the application will use it to get a database connection from the right datasource.

The symptom is: after running the application for a few hours, suddenly, userA of companyA will see data from companyB. This is of course very scary!

We try to diagnose this and can think of 3 possible problems:

1) JDBC driver has bugs - we have been using jTDS 0.71 but we also downloaded and tried jNetDirect's JSQLDirect. We were able to repeat the problem with both drivers, so we can rule out JDBC driver bugs.

2) Our code has bugs - but this is the same code we ran on weblogic for the last two years. The only thing I changed to migrate to JBoss in order to get datasource was to add "java:" as a prefix to the datasource JNDI string. The chance is slim for bugs on our side.

3) Is there any possibility that connection objects in JBoss can be sticky about the datasource they are associated with? It seemed to us that when we try to obtain a connection associated with datasource for companyA, we were given a connection associated with datasource for companyB.

Can someone think of any bugs or configuration that we should know of?

Appreciate the help because our migration is hanging in the balance...

Thanks

[starksm64]

File a bug report in jira with the datasource configurations and example usage of the datasource where the data gets mixed up.
http://jira.jboss.com/jira/browse/JBAS

Enable trace level logging on the org.jboss.resource category in the conf/log4j.xml to determine what is going on in the jca layer:

[ckokotsis]

quick suggestion that may be way off the mark but such behavior would occur as a result of ejb instances not having their member values re-initialised when retrieved from the instance pool.

eg>

1. retrieve instance of company bean from pool and populate with company A data.

2. passivate and return bean to instance pool

3. retrieve instance of company bean (previously populated with company A data) and populate with company B data.

if company B data partial, and subject to incorrect ejb coding, company bean B will have old values still populated from previous company A population. This will be seen after some time as bean instances within the pool are re-used.

Why u wouldn't see this b4 under web logic don't know. If this is the fix let me know.

[adrian.brock]

File a bug report in jira with the datasource configurations and example usage of the datasource where the data gets mixed up.
http://jira.jboss.com/jira/browse/JBAS

Enable trace level logging on the org.jboss.resource category in the conf/log4j.xml to determine what is going on in the jca layer:

<category name="org.jboss.resource">
<priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>

NO. HE SHOULD USE SEARCH OR READ THE DOCUMENTATION ABOUT JCA
SECURITY CONFIGURATION.

I answered this question earlier this month. I'm not going to repeat myself.
The purpose of this forum is not to repeatedly provide the same answers to lazy users.

Where's my "move redundant post to lazy users forum" button I have been asking for? :-)

[adrian.brock]

OK, I relented and added it to the FAQ, along with the other common error.
I doubt this will stop people still posting the question to the forums :-(

http://www.jboss.org/wiki/Wiki.jsp?page=FAQJCASubPooling

[dkoon]

It happens ckokotsis is correct. Our problem was due to an incorrect ejbLoad() coding where we did not refresh state after the first time the EJB was loaded.

The reason this incorrect ejbLoad() caused our symptom is that when user of
companyA signed in, JBoss went to cache/bean pool to get one existing
instance. It happened that there was a companyEJB available but it was used as
companyB before with companyB data. To change it to companyA, JBoss fired
ejbActivate() which in our code correctly assigned it the primary key of
companyA. Then JBoss fired ejbLoad() which in our code incorrectly refused to
reload data (because it loaded data once when it was first used as companyB).
Even though the key is companyA, the data is companyB!

The reason why this code had been working on the Weblogic side was likely due
to differences in EJB container implementation between the two application
servers. It seems like Weblogic does not trust programmers refreshing the
state in ejbLoad() that it resets all instance variables when it trys to reuse
an EJB from cache/bean pool. Anyway, if we would have coded ejbLoad()
correctly this symptom should have happened.

I fixed this problem on April 1st by forcing ejbLoad() to reload data everytime.

We tested it many times since and the symptom had disappeared.