Announcement Announcement Module
Collapse
No announcement yet.
Transactions with different attributes Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Transactions with different attributes

    Does anyone know if I have a method that has a transactional attribute of propergation=REQUIRED_NEW why it doesn't start in a new transaction? I have a method that is already running in a tx which calls other methods one of which is a method with REQUIRED_NEW attribute in the finally block. This however does not seem to want to start a new tx. This causes a problem when an exception is raised because the status updates that indciate a failed status get rolled back after the method completes. Any pointer tips would be helpful. Could I use AOP @AfterThrowing at all to perform the functionality if you cannot start a transaction in the finally block? And is possible to do it declaratively too? When there are no errors everything works fine.

    @Transactional
    public void processor(...) {

    //start tx1

    process feed in a separate thread and transaction. This creates a new transaction for each thread and also commits on thread/completion. This all works.

    //tx1 resumed
    additional processing performed

    status=SUCCESS
    catch (Exception e) {
    set status=FAILED
    throw new AppSpecificException()
    }

    finally () {
    dosomething()
    // exect this method to happen in new tx but it doesnt
    updateStatus(status)

    }

    @Transactional(propergation=Propergation.REQUIRED_ NEW)
    updateStatus(Status) {
    ....
    }


    }

  • #2
    Please use [ code][/code ] tags when posting code that way it remains readable.

    I suggest chapter 6 of the reference guide this explains the way spring uses aop. In short you can only add transactions to methods which are externally called, your method is called internally. Again read chapter 6 this explains the aop approach of spring.

    If you don't want this you will have to use a fullblown AOP solution with loadtime or compiletime weaving.

    Comment


    • #3
      Apologies for the code not in tags.

      The original reason for trying to create the a new transaction was to ensure some changes persisted even in the event of a rollback being performed. I think maybe a better way to solve the problem if to perform some sort of post processing after the transaction proxy has rolled back. I've had a look at chapter 6 and I was thinking of creating an afterThrowing aspect which could perform the processing. Is this the best approach or is there a way of configuring the transactional proxy to call a specified method for rollback processing. By doing it this way I wouldnt need to create the aspect.

      Thanks for your reply

      Comment

      Working...
      X