Grails
  1. Grails
  2. GRAILS-7093

Better support to programmatic transactions (withTransaction closure extension/changing)

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Persistence
    • Labels:
      None
    • Patch Submitted:
      Yes

      Description

      It's just a suggestion, but i really believe it would be a useful improvement:

      Apparently, withTransaction supports only propagation "required". This could be enough for regular applications, but it "fails" when you need a fine-grained transaction control.

      The suggested improvement is to offer another closure or to change withTransaction definition (HibernatePluginSupport.groovy) to support additional properties. These properties will be used to configure TransactionTemplate instance. I've written something similar in other project:

          def ctx = grailsApplication.mainContext
          grailsApplication.domainClasses.each {
            domainClass ->
      	domainClass.metaClass.static.withNewTransaction = {
      	  properties = [propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW],
      	  Closure callable ->
      	    def template = new TransactionTemplate(ctx.getBean('transactionManager'))
      	    properties.each {
      	      property ->
      		template[property.key] = property.value
      	    }
      	    template.execute({status ->
      	      callable.call(status)
      			     } as TransactionCallback)
              }
          }
      

      So we can easily start a new different transaction (even inside a Service class method/closure):

      MyDomainClass.withNewTransaction = {
         // Your code here
      }
      

      or explicitly:

      MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW) = {
         // Your code here
      }
      

      or even something more complex:

      MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_NESTED, isolationLevelName: 'ISOLATION_READ_UNCOMMITTED') = {
         // Your code here
      }
      

      It makes more sense to me to change withTransaction implementation than adding another closure because not every propagation type will create a "new transaction".

      For a new closure implementation, properties could be initialized as the sample (it's just a suggestion).
      For a changing in withTransaction implementation, properties should be initialized as an empty Map (properties = [:]) or null map (with null check), for backward compatibility.

      Reference:
      http://grails.org/doc/latest/ref/Domain%20Classes/withTransaction.html
      http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/TransactionDefinition.html#PROPAGATION_REQUIRED
      http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/support/TransactionTemplate.html

      Thanks!

        Issue Links

          Activity

          Daniel Henrique Alves Lima created issue -
          Luke Daley made changes -
          Field Original Value New Value
          Link This issue duplicates GRAILS-6630 [ GRAILS-6630 ]
          Luke Daley made changes -
          Description It's just a suggestion, but i really believe it would be a useful improvement:

          Apparently, withTransaction supports only propagation "required". This could be enough for regular applications, but it "fails" when you need a fine-grained transaction control.

          The suggested improvement is to offer another closure or to change withTransaction definition (HibernatePluginSupport.groovy) to support additional properties. These properties will be used to configure TransactionTemplate instance. I've written something similar in other project:


              def ctx = grailsApplication.mainContext
              grailsApplication.domainClasses.each {
                domainClass ->
          domainClass.metaClass.static.withNewTransaction = {
          properties = [propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW],
          Closure callable ->
          def template = new TransactionTemplate(ctx.getBean('transactionManager'))
          properties.each {
          property ->
          template[property.key] = property.value
          }
          template.execute({status ->
          callable.call(status)
          } as TransactionCallback)
                  }
              }

          So we can easily start a new different transaction (even inside a Service class method/closure):

          MyDomainClass.withNewTransaction = {
             // Your code here
          }

          or explicitly:

          MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW) = {
             // Your code here
          }

          or even something more complex:

          MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_NESTED, isolationLevelName: 'ISOLATION_READ_UNCOMMITTED') = {
             // Your code here
          }


          It makes more sense to me to change withTransaction implementation than adding another closure because not every propagation type will create a "new transaction".

          For a new closure implementation, properties could be initialized as the sample (it's just a suggestion).
          For a changing in withTransaction implementation, properties should be initialized as an empty Map (properties = [:]) or null map (with null check), for backward compatibility.



          Reference:
          http://grails.org/doc/latest/ref/Domain%20Classes/withTransaction.html
          http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/TransactionDefinition.html#PROPAGATION_REQUIRED
          http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/support/TransactionTemplate.html


          Thanks!
          It's just a suggestion, but i really believe it would be a useful improvement:

          Apparently, withTransaction supports only propagation "required". This could be enough for regular applications, but it "fails" when you need a fine-grained transaction control.

          The suggested improvement is to offer another closure or to change withTransaction definition (HibernatePluginSupport.groovy) to support additional properties. These properties will be used to configure TransactionTemplate instance. I've written something similar in other project:

          {code}
              def ctx = grailsApplication.mainContext
              grailsApplication.domainClasses.each {
                domainClass ->
          domainClass.metaClass.static.withNewTransaction = {
          properties = [propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW],
          Closure callable ->
          def template = new TransactionTemplate(ctx.getBean('transactionManager'))
          properties.each {
          property ->
          template[property.key] = property.value
          }
          template.execute({status ->
          callable.call(status)
          } as TransactionCallback)
                  }
              }
          {code}

          So we can easily start a new different transaction (even inside a Service class method/closure):

          {code}
          MyDomainClass.withNewTransaction = {
             // Your code here
          }
          {code}

          or explicitly:

          {code}
          MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_REQUIRES_NEW) = {
             // Your code here
          }
          {code}

          or even something more complex:

          {code}
          MyDomainClass.withNewTransaction(propagationBehavior: TransactionDefinition.PROPAGATION_NESTED, isolationLevelName: 'ISOLATION_READ_UNCOMMITTED') = {
             // Your code here
          }
          {code}

          It makes more sense to me to change withTransaction implementation than adding another closure because not every propagation type will create a "new transaction".

          For a new closure implementation, properties could be initialized as the sample (it's just a suggestion).
          For a changing in withTransaction implementation, properties should be initialized as an empty Map (properties = [:]) or null map (with null check), for backward compatibility.



          Reference:
          http://grails.org/doc/latest/ref/Domain%20Classes/withTransaction.html
          http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/TransactionDefinition.html#PROPAGATION_REQUIRED
          http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/transaction/support/TransactionTemplate.html


          Thanks!
          Jeff Scott Brown made changes -
          Fix Version/s 1.3.7 [ 17032 ]
          Daniel Henrique Alves Lima made changes -
          Attachment HibernatePluginSupport.patch [ 54286 ]
          Daniel Henrique Alves Lima made changes -
          Attachment HibernatePluginSupport.patch [ 54286 ]
          Daniel Henrique Alves Lima made changes -
          Attachment HibernatePluginSupport.patch [ 54289 ]
          Graeme Rocher made changes -
          Priority Major [ 3 ] Blocker [ 1 ]
          Patch Submitted [Yes]
          Fix Version/s 1.4-M1 [ 16812 ]
          Contegix Support made changes -
          Project Import Thu Mar 24 21:22:24 CDT 2011 [ 1301019744151 ]
          Jeff Scott Brown made changes -
          Assignee Jeff Brown [ brownj ]
          Graeme Rocher made changes -
          Fix Version/s 1.4-M1 [ 11040 ]
          Fix Version/s 1.4-M2 [ 12504 ]
          Jeff Scott Brown made changes -
          Priority Blocker [ 1 ] Major [ 3 ]
          Jeff Scott Brown made changes -
          Fix Version/s 2.0-M1 [ 12504 ]
          Fix Version/s 2.0-RC1 [ 12803 ]
          Burt Beckwith made changes -
          Workflow jira [ 30522 ] Grails [ 40235 ]
          Burt Beckwith made changes -
          Workflow Grails [ 40235 ] Copy of Grails [ 47668 ]
          Burt Beckwith made changes -
          Workflow Copy of Grails [ 47668 ] Grails [ 55078 ]
          Burt Beckwith made changes -
          Workflow Grails [ 55078 ] Grails2 [ 62629 ]
          Jeff Scott Brown made changes -
          Fix Version/s 2.1 [ 12801 ]
          Fix Version/s 2.0-RC1 [ 12803 ]
          Burt Beckwith made changes -
          Workflow Grails2 [ 62629 ] jira [ 71124 ]
          Burt Beckwith made changes -
          Workflow jira [ 71124 ] Grails2 [ 79156 ]
          Peter Ledbrook made changes -
          Last Reviewed 01/Jan/10
          Peter Ledbrook made changes -
          Workflow Grails2 [ 79156 ] jira [ 88808 ]
          Peter Ledbrook made changes -
          Workflow jira [ 88808 ] Grails2 [ 96954 ]
          Graeme Rocher made changes -
          Fix Version/s 2.1 [ 13117 ]
          Fix Version/s 2.1-RC1 [ 12801 ]
          Graeme Rocher made changes -
          Fix Version/s 2.1 [ 13125 ]
          Fix Version/s 2.1-RC2 [ 13117 ]
          Graeme Rocher made changes -
          Fix Version/s 2.2 [ 13093 ]
          Fix Version/s 2.1 [ 13125 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3 [ 13311 ]
          Fix Version/s 2.2-RC1 [ 13093 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3-M2 [ 13457 ]
          Fix Version/s 2.3-M1 [ 13311 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3-RC1 [ 13458 ]
          Fix Version/s 2.3-M2 [ 13457 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3-RC2 [ 13482 ]
          Fix Version/s 2.3-RC1 [ 13458 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3.1 [ 13502 ]
          Fix Version/s 2.3-RC2 [ 13482 ]
          Graeme Rocher made changes -
          Fix Version/s 2.3.1 [ 13502 ]
          Graeme Rocher made changes -
          Fix Version/s 2.4 [ 13506 ]

            People

            • Assignee:
              Jeff Scott Brown
              Reporter:
              Daniel Henrique Alves Lima
            • Votes:
              24 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Last Reviewed:

                Development