Announcement Announcement Module
No announcement yet.
Isolation level - READ_COMMITTED_SNAPSHOT Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Isolation level - READ_COMMITTED_SNAPSHOT

    Hi All,

    In my use case, while running the same job in multiple jvm with different job parameters i am getting Deadlocks(If i am running in single jvm it is working fine).

    My batch is long running batch so I have enable the




    <bean id="batchSessionFactory" class="org.springframework.orm.hibernate3.LocalSes sionFactoryBean">
    <property name="mappingLocations">
    <property name="hibernateProperties">
    <prop key="hibernate.dialect">org.hibernate.dialect.SQLS erverDialect
    <prop key="hibernate.show_sql">false</prop>
    <prop key="hibernate.cache.use_second_level_cache">true</prop>
    <prop key="hibernate.cache.generate_statistics">true</prop>
    <prop key="hibernate.connection.isolation">4096</prop>
    <property name="dataSource">
    <ref bean="dataSource" />

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value=" r" />
    <property name="url"
    <property name="username" value="XXX" />
    <property name="password" value="YYYY" />


    Victim Resource Owner:
    2011-06-28 15:48:55.31 spid4s ResType:LockOwner Stype:'OR'Xdes:0x057A66E0 Mode: U SPID:81 BatchID:0 ECID:0 TaskProxy0x057C8378) Value:0x39f76a0 Cost0/35180)
    2011-06-28 15:48:55.31 spid15s deadlock-list
    2011-06-28 15:48:55.31 spid15s deadlock victim=process8da898
    2011-06-28 15:48:55.31 spid15s process-list
    2011-06-28 15:48:55.32 spid15s process id=process8da898 taskpriority=0 logused=35180 waitresource=KEY: 13:1217114567213056 (7a019dd49262) waittime=3937 ownerId=270765 transactionname=implicit_transaction lasttranstarted=2011-06-28T15:48:33.937 XDES=0x57a66e0 lockMode=U schedulerid=1 kpid=2008 status=suspended spid=81 sbid=0 ecid=0 priority=0 transcount=2 lastbatchstarted=2011-06-28T15:48:51.310 lastbatchcompleted=2011-06-28T15:48:51.283 clientapp=Microsoft SQL Server JDBC Driver hostname=tttttttt hostpid=0 loginname=xxx isolationlevel=read committed (2) xactid=270765 currentdb=13 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128058
    2011-06-28 15:48:55.32 spid15s executionStack


    I have configured the isolation level as READ_COMMITTED_SNAPSHOT in mapping file. but while checking deadlock Victim, isolation level is READ_COMMITTED.

    1. Spring Transaction manager will override the READ_COMMITTED_SNAPSHOT to READ_COMMITTED?

    2. How to configure READ_COMMITTED_SNAPSHOT isolation level in spring batch?

    thanks for your reply in advance.

  • #2
    As far as I know READ_COMMITTED_SNAPSHOT is a SQL Server platform feature, so you won't find any settings for it in Spring as such (or maybe it maps to READ_UNCOMMITTED?). You didn't say which query was deadlocking - if it is an INSERT on BATCH_JOB_INSTANCE then the isolation level was set by Spring Batch to prevent you from accidentally launching the same Job twice concurrently. You can change the setting in the JobRepository configuration via namespace or factory bean definition, and in your case DEFAULT would be the right setting. But that deadlock is probably telling you something useful - you shouldn't be launching two identical JobInstances at the same time.


    • #3
      Thanks for your reply Dave.

      We tried with the suggestion of changing the isolation level to DEFAULT. But, still the deadlock occurs. I have attached the dead lock graph from the server for your reference.

      My business scenario exists such that a new record is created and the same record is updated in the further flow. At these instant of updations, the dead lock occurs. The business is such that unique items are processed in the individual JVM and thus there is no intersection of the items.But, we could not decipher the reason for the deadlock.

      The same code works fine in a single JVM.

      please enlighten us some way to find the cause and resolve the issue. Let me know in case of any related information.


      • #4
        I probably can't really help with a deadlock in user tables. If there is anything you can do in the Spring config then a Java stack trace from the client would be more useful.


        • #5
          Thanks a lot Dave.
          Can you give us any idea on the loop holes that we have to look in for the deadlock occuring in user tables.

          I have attached the error log.


          • #6
            Deadlocks are notoriously tricky on SQL Server and friends. the best advice would be to switch to Oracle.

            I think there's something wrong with the forum site. Can you just paste the stack trace inside some [code][/code] tags?


            • #7
              The Stack trace :


              [2011-06-29 13:08:39,847] [1001_main_Child] ERROR org.springframework.batch.core.step.AbstractStep - Encountered an error executing the step
              common.exception.SystemException: CMNDA0001E: A data access system exception has occured. Implementation: Hibernate. Cause: org.hibernate.exception.LockAcquisitionException: could not update: [moneyoperations.domain.PlanContractualPaymentEleme ntDo#component[planNumber,elementNumber]{elementNumber=000057, planNumber=0XXXXX4 }]
              at common.exception.ExceptionUtils.createHibernateSys temException(
              at common.exception.ExceptionUtils.createHibernateSys temException(
              at moneyoperations.dao.hibernate.ContractualPaymentEl ementDaoHibernate.recordPlanContractualPaymentElem entList( :288)
              at lementHelperBo.recordPlanContractualPaymentElement List( 3775)
              at lementBo.recordPlanContractualPaymentElementList(P
              at lementBo.updatePlanContractualPaymentElementForPre miumIncreaseAmount(PlanCommissionForPaymentElement
              at lementBo.variationUpdateForPlanContractualPaymentE lement(
              at mentBo.variationUpdateForPlanContractualPaymentEle ment(
              at lementHelperBo.updatePlanContractualPaymentElement Variation(PlanCommissionForPaymentElementHelperBo. java:640)
              at mentBo.updatePlanContractualPaymentElementVariatio n(
              at ontractualPaymentElementBoDelegateJava.updatePlanC ontractualPaymentElementVariation(PlanContractualP
              at planmanagement.process.PlanGrowthInstructionProces s.processPlanGrowthInstructionSecondStage(PlanGrow
              at planmanagement.process.PlanAdministrationManagemen tProcess.processPlanGrowthInstructionSecondStage(P
              at batch.autoescalations.processor.AutomaticEscalatio nStageOneProcessor.process(AutomaticEscalationStag
              at batch.autoescalations.processor.AutomaticEscalatio nStageOneProcessor.process(AutomaticEscalationStag
              at batch.core.processor.BatchRunTaskListProcessorWrap per.process( 146)
              at org.springframework.batch.core.step.item.SimpleChu nkProcessor.doProcess( 8)
              at org.springframework.batch.core.step.item.SimpleChu nkProcessor.transform( 0)
              at org.springframework.batch.core.step.item.SimpleChu nkProcessor.process(
              at org.springframework.batch.core.step.item.ChunkOrie ntedTasklet.execute(
              at org.springframework.batch.core.step.tasklet.Taskle tStep$ChunkTransactionCallback.doInTransaction(Tas
              at nTemplate.execute(
              at org.springframework.batch.core.step.tasklet.Taskle tStep$2.doInChunkContext(
              at org.springframework.batch.core.scope.context.StepC ontextRepeatCallback.doInIteration(StepContextRepe
              at plate.getNextResult(
              at plate.executeInternal(
              at plate.iterate(
              at org.springframework.batch.core.step.tasklet.Taskle tStep.doExecute(
              at org.springframework.batch.core.step.AbstractStep.e xecute(
              at org.springframework.batch.core.job.SimpleStepHandl er.handleStep(
              at org.springframework.batch.core.job.flow.JobFlowExe cutor.executeStep(
              at ate.StepState.handle(
              at mpleFlow.resume(
              at mpleFlow.start(
              at Execute(
              at org.springframework.batch.core.job.AbstractJob.exe cute(
              at leJobLauncher$
              at org.springframework.core.task.SyncTaskExecutor.exe cute(
              at leJobOperator.start(
              at batch.core.launch.StepControllerLauncher$
              at Source)
              Caused by: org.hibernate.exception.LockAcquisitionException: could not update: [moneyoperations.domain.PlanContractualPaymentEleme ntDo#component[planNumber,elementNumber]{elementNumber=000057, planNumber=040737119X4 }]
              at org.hibernate.exception.SQLStateConverter.convert(
              at org.hibernate.exception.JDBCExceptionHelper.conver t(
              at org.hibernate.persister.entity.AbstractEntityPersi ster.update(
              at org.hibernate.persister.entity.AbstractEntityPersi ster.updateOrInsert( 325)
              at org.hibernate.persister.entity.AbstractEntityPersi ster.update(
              at org.hibernate.action.EntityUpdateAction.execute(En
              at org.hibernate.engine.ActionQueue.execute(ActionQue
              at org.hibernate.engine.ActionQueue.executeActions(Ac
              at org.hibernate.engine.ActionQueue.executeActions(Ac
              at org.hibernate.event.def.AbstractFlushingEventListe ner.performExecutions(AbstractFlushingEventListene
              at org.hibernate.event.def.DefaultFlushEventListener. onFlush(
              at org.hibernate.impl.SessionImpl.flush(SessionImpl.j ava:1028)
              at moneyoperations.dao.hibernate.ContractualPaymentEl ementDaoHibernate.recordPlanContractualPaymentElem entList( :285)
              ... 39 more
              Caused by: Transaction (Process ID 81) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
              at keFromDatabaseError(
              at tNextResult(
              at ement.doExecutePreparedStatement(SQLServerPrepared
              at ement$PrepStmtExecCmd.doExecute(SQLServerPreparedS
              at xecuteCommand(
              at ecuteCommand(
              at ecuteStatement(
              at ement.executeUpdate(SQLServerPreparedStatement.jav a:306)
              at org.apache.commons.dbcp.DelegatingPreparedStatemen t.executeUpdate( 05)
              at org.apache.commons.dbcp.DelegatingPreparedStatemen t.executeUpdate( 05)
              at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(N
              at org.hibernate.persister.entity.AbstractEntityPersi ster.update(
              ... 49 more


              • #8
                Thanks for your reply Dave.

                I have set the TransactionIsolation as 4096 (ie..READ_COMMITTED_SNAPSHOT), While getting session from the SessionFactoryUtils. Now there is no dead lock happened.

                While setting the same in hibernateProperties, hibernate / Spring didn't pick it up. what may be the reason?


                public synchronized Session getCurrentSession() {

                LOGGER.debug("Enter getCurrentSession.");

                Session currentSession = SessionFactoryUtils.getSession(sessionFactory, true);
                try {
                currentSession.connection().setTransactionIsolatio n(4096);
                } catch (HibernateException e) {
                LOGGER.error("HibernateException: " + e);
                } catch (SQLException e) {
                LOGGER.error("SQLException: " + e);

                LOGGER.debug("Exit getCurrentSession.");

                return currentSession;



                • #9
                  OK, there's nothing funny about that stack trace. You are in a normal chunk transaction started by the TaskletStep. The isolation level for the transaction, if you haven't changed it, should be DEFAULT (meaning Spring won't modify the Connection). Maybe you need to configure your custom default level in the DataSource? Depending on the DataSource and driver you are using there might be a native way of doing that or you could look into the DataSource implementations in Spring (one of them is for setting isolation levels).

                  I know you don't want these locks if you can avoid them, but if you just set that exception to be retryable Spring Batch will retry the transaction for you, and that's often the only way round deadlocks.