views:

615

answers:

1

Hi. In my J2ee web application I am using a datasource accessed stored in the weblogic server and accessed through jndi. In normal datasource bean declaration there is a property defaultAutoCommit which can be set to false. Is there a similar property or is there a way to set something like this when using datasource in JNDI. Because currently my rollback won't work using JNDI. But when I normally define my datasource in the application context with defaultAutoCommit set to false my rollback works.

JNDI Data source:

<bean id="TerasolunaDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
         <property name="jndiName" value="dataSource" />
</bean>

Normal Data Source defined in application context

 <bean id="dataSource"
    class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName"
        value="oracle.jdbc.OracleDriver" />
    <property name="url"
        value="jdbc:oracle:thin:@192.168.178.82:1521:anicom" />
    <property name="username" value="jay" />
    <property name="password" value="jay" />
    <property name="initialSize" value="5" />
    <property name="maxActive" value="10" />
    <property name="defaultAutoCommit" value="false" />
 </bean
+1  A: 

You need a JTA transaction manager and transaction logic. It's not just auto commit.

duffymo
when i used jndi i used datasourcetransactionmanager. Will this not work?
cedric
There's a WebLogicJtaTransactionManager. I'd recommend trying that.
duffymo
It worked with DataTransactionManager. But I changed something with the declaration of the bean. I tried to transfer the declaration to the application context from the struts-config.xml and it worked after that.
cedric
Spring beans must all be in app context. Only Struts belongs in struts-config.xml. That would explain your problem.
duffymo
I am going to try transferring declaratio of this beans to the application context. Will this not pose any problem in the future. Like the application context will be messed up or object instance issues for different clients accessing the application?
cedric
I don't see how it'll mess up the app context. The 'messed up' part is NOT having them in the app context, which is where they belong. Beans that aren't in the app context are not under Spring's control.
duffymo