Forum: Other

Post: Commit/Abort processing in context of Spring

Commit/Abort processing in context of Spring
chbussler
Apr 4, 2010
Hi,

in Spring there is the possibility to set transaction boundaries at the application level (http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html). This means that the commit or abort of a transaction is decided by the application (e.g. bean method), not by the database. Do you plan to integrate the Volt transaction management with Spring so that I could make use of the Spring transaction features?

As far as I understand a transaction in Voltdb correspond to one stored procedure invocation and VoltDB makes the decision to commit or abort (unless the logic in the stored procedure forces an abort by throwing a VoltAbortException; but that would be the stored procedure logic doing it).

Thanks,
Christoph
You understand correctly.
jhugg
Apr 5, 2010
In VoltDB, the stored procedure and the transaction are one and the same. If the procedure exits successfully, then the transaction will commit. If an exception is thrown, such as a VoltAbortException, then the transaction will roll back. So while the decision to rollback/commit can still be part of application logic, it must be made within a procedure run on the database.

This fundamental coupling of transaction and procedure is one the core design choices that make VoltDB fast. Without it, a transaction may have to wait on a network round trip to another machine to decide how to proceed. Because VoltDB has no waits inside a transaction, it can run each in a single-threaded pipeline. This is one way VoltDB manages to be orders of magnitude faster than other RDBMSs, and it's an intentional tradeoff.

So it's unlikely this behavior will change in VoltDB anytime soon.

-John Hugg
Hi John, thanks a lot. This
chbussler
Apr 6, 2010
In VoltDB, the stored procedure and the transaction are one and the same. If the procedure exits successfully, then the transaction will commit. If an exception is thrown, such as a VoltAbortException, then the transaction will roll back. So while the decision to rollback/commit can still be part of application logic, it must be made within a procedure run on the database...

-John Hugg


Hi John,

thanks a lot. This means that from an application design viewpoint any decision logic to abort must be part of a stored procedure. After the procedure succeeded, no logic can influence the transaction outcome any more.

Not sure yet what the application design implications are, but I'll see what this means down the road. It does not feel to be a problem at all.

Thanks,
Christoph
Two-phase Transactions
henning
Apr 16, 2010
Hi John,

thanks a lot. This means that from an application design viewpoint any decision logic to abort must be part of a stored procedure. After the procedure succeeded, no logic can influence the transaction outcome any more.

Not sure yet what the application design implications are, but I'll see what this means down the road. It does not feel to be a problem at all.

Thanks,
Christoph


Not sure if this helps, but for many cases, it may not be perfectly true that "any decision logic to abort must be part of a stored procedure." even though "In VoltDB, the stored procedure and the transaction are one and the same."

Essentially I'd be reasoning with two different definitions of what a transaction is. But to split transactions up seems to be a wise thing sometimes when using VoltDB. I have been advised so by Tim I think on one occasion.

What you have then, obviously, is


  • one logical transaction, i.e.: what your application logic thinks of as instructions that belong together, all or none. And,
  • two database transactions which 'are' the stored procedures. And that represent two parts of the logical transaction.


If the first part is read-only then you could make the decision to abort in the Client source, between the database transactions, i.e. stored procedure calls. For asynchronous calls, we'd probably be speaking about callback functions, which also reside on the client, I think.

Are these what the H-Store paper calls two-phase transactions?

Pg. 4:"Some transaction classes are two-phase (or can be made to be two phase.) In phase one there are a collection of read-only operations. Based on the result of these queries, the transaction may be aborted. Phase two then consists of a collection of queries and updates where there can be no possibility of an integrity violation. H-Store will exploit the two-phase property to eliminate the undo log. We have observed that many transactions, including those in TPC-C, are two-phase."

Please correct me.

Thanks,
Henning
2-phase vs. Spring logic
chbussler
Apr 17, 2010
Not sure if this helps, but for many cases, it may not be perfectly true that "any decision logic to abort must be part of a stored procedure." even though "In VoltDB, the stored procedure and the transaction are one and the same."..
Henning


Hi Henning,

yes, it might be possible for me to divide up my logical transaction into two parts as you described. In that case the client can choose to not run the second database transaction. No problem here.

For those cases where I cannot make this separation, I have to put all in one procedure and try to keep the logic that determines the success/abort as small as possible. No problem either, at least in principle.

Independent of approach, the stored procedure or VoltDB makes the decision to succeed or abort. This means that when using Spring, their transaction mechanism is not of use any more for me as it does not coordinate with VoltDB at all.

Furthermore, the way business logic is implemented it probably going to change from how the code is structured. I am not there yet in terms of what it really means, but I expect it.

Thanks,
Christoph