Spring, Hibernate, MySQL - How Transactions work - Conclusion/Questions**

I work with the Spring Framework 3.0.5, Hibernate 3.6 and MySQL Server 5.1. Ive got some questions regarding the transaction management in general. I personally use declarative transaction management from spring. It would be great if you could answer my questions with yes/no (or correct/incorrect) and maybe, if necessary, give short explanations. It would be nice if several people would answer in case that there are different opinions. Thank you :-)

1) Would you say this sentences is correct: A DBMS is responsible for the generally implementation of transactions and their behaviour.

1) B) Maybe it would be better to say: A DBMS is responsible for the generally implementation of transactions and the behaviour of the Database (for example when a transaction is rolled back).

2) Hibernate just uses the Database Connection. It needs Transactions, but it doesnt configurate any(!) settings regarding the transactions and their behaviour.

3) But: to work with Transactions, Hibernate needs to KNOW, where Transactions start, are commited and need to be rolled back.

4) Does Hibernate also need to know what in case of roll back happens? I think no, because this should be defined in the DBMS. (that means: which tables shall be locked, which database operations shall be made undone, and so on, correct?)

5) For 3), programmatic or declarative transaction management can be used.

6) When using programmativ transaction management, everything which Hibernate needs to know (3)) can be written in the source code manually by the developer.

7) For declarative transaction managament an additional framework to hibernate is necessary, FOR EXAMPLE Spring.

8) Spring manages transactions. Its like a frame for them. It triggers the actions, like starting and rolling back a transaction.

9) Spring can also define for which exceptions rollback must or must not happen

10) Does Spring any additional things when roll back happens? I think the database is responsible for roll back, spring just triggers it, right? Its just to make sure....

Thank you :-)

---

[EDIT] This is an answer to duffymo, it was too long for a comment and I am not allowed to answer my own question within 8 hours, thats why for now Ive got to put it here. Sorry.

@duffymo

Interesting answers, here are my thoughts about it:

1. So we agree, that the behaviour of the database (of course!) in case when transactions are rolled back or commited is implemented or defined directly by the DBMS, correct? I know the Transaction Manager, (PlatformTransactionManager), but I really think that it just initiates transactions, roll back, and commit. That means, it is not reponsible to HOW transactions are handled by the database, correct? I guess my verbalization was mistakable, I updated it (1B)

2. Thats a little bit abstract to me. Does it mean my sentences was correct or wasnt it :-)

3. How can it mark this by itself? I think this must be done by the developer? I think of "start tx, commit..." which can be done in the source code by a developer

4. I agree. Thats one thing I find a little bit difficult to understand in all those documentations. They tell about which transactions are catched and which arent, but in case to find out how to handle them, you have to find out by yourself. I was confused in the beginning, because I was not sure if I could even surround the call of a transactional-annotated method with a try/catch-block in order to catch an exception and to inform a user. Its simply not enough to have a transaction rolled back, I need the user to be informed. Thats why I almost everywhere use try/catch - how do you handle this?

5. This is one point I dont understand. Spring offers programmatic and declarative transaction management. If Spring itselfs manages the transactions, of course declarative transman is used. Programmatic is... in my eyes.. simply programmatic. Im not sure if you can say "Hibernate==programmatic", because you can use Hibernate with both, programmatic and declarative transaction management. Maybe its possible to say that hibernate does not offer ITSELF declarative transaction management.

6. I didnt even know it was possible to do this "in JDBC" - I must admit I dont know how this works in detail then. Somehow funny, that while reading you thought Im against the use of declarative transactions (if I did not misunderstand you), I really appreciate declarative transaction management. :-) I think its very easy to use and when reading through the code it is very understandable.

7. If I want to use Hibernate with declarative transaction management, I need an additional framework like Spring. Because declarative means, that an additional framework "does all the work you would have to do programmatically". (like starting tx, commit, roll back). And I also guess Spring might not be the only framework which offers declarative transaction management for hibernate. But the main point in my question wa开发者_开发问答s, that it is not possible to use declarative transaction management for hibernate without using an additional framework. I hope I verbalized it correctly now :-)

8. ok, correct. so the transaction manager triggers roll back, starting tx, and so on

9. ok..

10. sorry :-)

I just like to understand how things work. I read through the documentations again and again, but if you are learning everything by yourself, its important to understand the essential facts. Thats why Im asking :-) Thank you for your help! :-)

---

Here's my take:

1. Ultimately the commit/rollback behavior is done in the relational database, but it's not completely accurate to give all responsibility to the database. When you use Spring, JDBC, and a relational database together there's a middle tier piece that's involved, usually called a transaction manager.
2. Hibernate implements transactional logic programmatically in objects.
3. Hibernate does mark the start and end of a transaction programmatically.
4. Hibernate might want to know if a transaction is rolled back; more importantly, your application will need to know so it can tell users.
5. Hibernate == programmatic; Spring == declarative.
6. Can be written by the developer. You can even do all of it in JDBC if you want. But there are good reasons for declarative transactions. (You sound like you're trying to justify not using them. I wonder why?)
7. Don't understand this - reword it.
8. The transaction managers take care of transactions.
9. Spring will throw the appropriate exceptions, yes.
10. You seem to be repeating the same questions over and over.

What's your real point here? I'd be curious to know.

You can always do this programmatically in JDBC. Ultimately this is what all Java solutions that use JDBC to interact with relational databases use, including Hibernate and Spring. Here's a template:

// prototypical write operation
public void update(Connection connection) throws SQLException
{
    connection.setAutoCommit(false);
    try
    {
        // SQL logic here
        connection.commit();  // if you get here, success
    } 
    catch (SQLException e)
    {
        try { if (connection != null) connection.rollback(); } catch (SQLException e) {}
        // might do some other things here (logging, etc.)
        // sql error codes will tell you why; spring translates these for you.
    }
    finally
    {
        // close statements here in individual try/catch blocks.
    }
}

---

1. yes
2. yes
3. yes, you tell Hibernate where the transaction start/end and it tells the DBMS
4. you're right, Hibernate does not need to know how to implement transaction in DBMS
5. yes
6. yes
7. yup
8. yes
9. yes
10. right, Spring just triggers it

From your question I guess you've already read transactions in Spring docs I suggest you also read this IBM developerWorks article on transactions