Atomikos Forum

I am running Tomcat with two WARs deployed in it. In my context.xml I have the following entry for Atomikos (URL, password and user properties have been left out of the example below for security reasons):

<Resource auth="Container" factory="com.atomikos.tomcat.BeanFactory" maxPoolSize="50" minPoolSize="5" name="jdbc/ASR_XA_Managed" type="com.atomikos.jdbc.AtomikosDataSourceBean" uniqueResourceName="AtomikosDataSourceJDBCOracle.ASR_WS" xaDataSourceClassName="oracle.jdbc.xa.client.OracleXADataSource" xaProperties.URL=... xaProperties.password=... xaProperties.user=.../>

My Spring config has the following bean:
<bean id="datasource.ASR_WS" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiName" value="java:comp/env/jdbc/ASRC_XA_Managed" />
    </bean>

This config is contained in a jar, say "MyJar.jar" that is used by two different WARs running in the same container. When I deploy my WARs, I get the following error:
Another resource already exists with name AtomikosDataSourceJDBCOracle.ASR_WS - pick a different name

The workaround is to define a second resource in my server's context.xml with a different name. The first WAR then uses the first resource and the second WAR the second resource.

Is there a way to avoid this? It would be much neater if the two WARs could share the same resource.

Hi Rik,

Thanks for the feedback!

One way to do this would be to modify the source code of the bean factory (http://www.atomikos.com/Documentation/Tomcat6Integration33#Bean_Factory_java) and cache lookups so they can be returned for later requests.

If the issues is serious enough then we could also add the possibility to tune the datasource behavior itself - not sure about that yet.

What is your view on this?

Thanks
Guy

What about adding a check in bean factory as mentioned here- http://blog.vinodsingh.com/2010/01/share-datasource-among-several.html

// see if this DataSource is already initialized then return cached object
// if available, else Atomikos will throw an exception
try {
    bean = IntraVmObjectRegistry.getResource(((AbstractDataSourceBean) bean).getUniqueResourceName());
    if (log.isInfoEnabled())
        log.info("Returning cached value of AbstractDataSourceBean (Atomikos): " + bean);

    return bean;
} catch (NameNotFoundException nfe) {
    // OK, it is not available go ahead and create one
}

Only downside here I see is that an internal API of Atomikos is used, which may change over the period.

Sounds good!

Thanks for the tip. BTW the internal API use is limited, and our datasource API is rather stable. At least the uniqueResourceName should be lasting for years to come.

Guy