春季交易+休眠

Question

We are using transaction management through declarative approach, we have specify that all the method which is start with update* must follow the transaction.

Suppose we have a transaction method updatePayroll() inside this method we are calling four another method, but our requirement is to rollback only in case of first two method get failed else no rollback is required. I don't know how to implement this as my updatePayroll() is transacted method so how it is possible to tell the spring that we need only two method's of updatePayroll() should be transacted.

code:

public void updatePayroll()
{
// below two methods of updateParyroll is required transaction where updatePayroll is transacted method through declarative approach.
updateLWPEmployees();

processSalary();

// below methods does not require transaction.
printSalarySlip();

sendEmail();
}

Thanks in advance.

Answer 1

if you want to avoid changes to the transaction management configuration, then

1. you can create a dummy class extending RuntimeException , lets call it NoRollBackException , now you need to configure the trasnaction manager to not rollback in case of the NoRollBackException , later you put the two methods printSalarySlip() and sendEmail() in a try catch block and throw the NoRollBackException .

or

1. (a more simpler approach) you could call the two methods ( printSalarySlip() and sendEmail() ) in a seperate function after the call to updatePayroll suceedes.

or

1. you can catcgh the exception thrown by the two methods and not allow the exception to be propogated.

all the above methods does exactly what you are looking for.

Answer 2

Why not write a transacted method including the first two methods? And then let the method updatePayroll() without transaction include this method?

Answer 3

Before saying any technical thing, i'll outline the fact that transactions aren't pure technical concept, i hope that this need isn't because you only want to avoid some technical dificulties you faced. We need to keep as possible unchanged the semantic of transaction rollback behavior following the trigering of an exception: ie when a technical problem(RuntimeException) is encountred you better let the transaction rollback(and this is the default behavior) because you didn't expect such a scenario, if you find out that it's technically incosistent, then probably this processing is not logically part of the transaction. Otherwise, if it's your exception that is thrown(a business exception, planed during design) then you have total control to rollback or not as explained in the first answear.

@woodpecker: the solution you proposed is not the same technically speaking when it comes to isolation, especially when we're trying to avoid dirty and repeatable reading