0

I'm coding my own data layer using JDBC for accessing SQL databases and one of the main components is the transaction manager.

I'm a little bit confused whether or not to support the nested transactions in this component. A sample code of a nested transaction is as follows:

tx1.begin();
... // do something with tx1
    tx2.begin();
    ... // do something with tx2
    tx2.commit();
...
tx1.commit();

During my past development experiments, I've never needed them and I think that they make the code more complex. But, I'm not sure that they are useless or useful. Can you give some example cases in which a nested transaction is required or at least advantageous? And what are the pros and cons of them?

To clarify my question and to explain what I mean by a transaction, I pasted my comment below:

I'm using JDBC. So, the transaction manager is independent of the underlying database. By transaction, I mean non-autoCommit JDBC connections. The transaction manager returns a transaction object with a non-autoCommit connection. The client code using this transcaction, commits and closes the connection by committing the transaction object.

Thanks in advance.

ovunccetin
  • 8,443
  • 5
  • 42
  • 53
  • 1
    What database? The semantics of 'nested' transactions vary greatly between vendors. – Remus Rusanu Oct 11 '13 at 07:35
  • I'm using JDBC. So, the transaction manager is independent of the underlying database. By transaction, I mean non-autoCommit JDBC connections. The transaction manager returns a transaction object with a non-autoCommit connection. The client code using this transcaction, commits and closes the connection by committing the transaction object. – ovunccetin Oct 11 '13 at 07:49
  • 1
    No client xact manager can be 'independent' of underlying resource manager. All they do is orchestrate, So JDBC cannot do magic, it will behave exactly as the underlying database allow it to behave. And will behave differently on different vendors. – Remus Rusanu Oct 11 '13 at 08:03
  • It is obvious that the transactions are realized by the underlying DBMS. However, JDBC provides an abstraction and my code benefits from this abstraction by making do with only features supported by the JDBC driver. So, I think the database type is not a big problem as long as it (and its JDBC driver) supports the transactions. My code will simply create a non-autoCommit JDBC connection and will commit&close it after the steps of an atomic process completed. Nevertheless, I can say that my code will operate on mostly MySQL (InnoDb) and Oracle. – ovunccetin Oct 11 '13 at 21:38

0 Answers0