Announcement Announcement Module
Collapse
No announcement yet.
Spring&Hibernate, DAO, Transactions, Management Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring&Hibernate, DAO, Transactions, Management

    Hello together,

    Im working on developing a webapplication with Spring 3.0.5, Hibernate 3.6 and MySQL Server 5.1.

    After researching a lot, I decided to write my DAO on plain Hibernate 3 API, because it was easy to understand and it didnt depend on spring.

    Today while googling I somehow accessed the spring reference 1.x and I read there, that in version 1.x there were disadvantages of using DAOs based on plain Hibernate 3 API

    "A further disadvantage of that DAO style is that Hibernate's getCurrentSession() feature just works within JTA transactions. It does not work with any other transaction strategy out-of-the-box, in particular not with local Hibernate transactions."
    In the documentation of todays Spring Version this cant be found. (Beside of this, I really didnt understand the part of not working with "local Hibernate transactions".) However, in todays Spring reference I found this:
    You can also use Hibernate local transactions easily, as shown in the following examples. In this case, you need to define a Hibernate LocalSessionFactoryBean, which your application code will use to obtain Hibernate Session instances.
    so I guess this isnt an issue anymore, correct?

    So, today, is there any disadvantage of writing a DAO this way? I couldnt find one. Using HibernateTemplate or other possibilities always were very cumbersome, DAO based on plain Hibernate 3 API isnt.

    Beside of this Ive got some additional questions which I could not get answered anywhere else, so since Im writing this post anyway, I wanted to ask if anybody knows if Hibernate forces us to use transactions? If yes, is it necessary too to use Springs Transaction Management for managing the transactions when you use spring and hibernate or isnt it?

    The problem with Hibernate Im facing is, that everywhere in the internet I find that using transactions is necessary! So I simply dont understand why it is possible to create myISAM tables with Hibernate and use myISAM database dialect, since MyISAM is not a transactional engine. I thought for using Hibernate you need transactions and therefor innodb tables. its really confusing me. Besides I found this article (http://community.jboss.org/wiki/Non-...uto-commitmode) about non-transactional data access with hibernate. I really dont understand this. If anyone has an idea, I would be grateful.

    Another question I have is that I read that in most applications declarative transaction management is recommended (I read this in spring documentation.), but I didnt find an answer WHY it is recommened. I would like to know this :-)

    Thank you!

  • #2
    Older versions of hibernate didn't have a contextual session and there was a hack needed to make it work with spring. The changed it after hibernate 3.0.1 and since then you can write plain hibernate dao's.... As of 2007/2008 it isn't recommended anymore to use HibernateTemplate/JpaTemplate...

    You have to use transactions with hibernate because else no sql will be issued to the database. Hibernate needs to know WHEN to commit (and to flush). Without transactions that isn't possible.

    Why declarative transactions are recommended because it is easier. You don't have to litter your code with

    Code:
    try {
     // start tx
     // do db stuff
     // commit
     } catch (someexception se) {
       rollback
     } finally {
       clean up used db resources etc.
     }
    With declarative tx you only have to write the 'do db stuff' part and can forget about the rest. It is all about productivity, clean code and you don't want to manage all that stuff manually (because you are going to forget to cleanup after yourself once in a while and then it is a happy debugging path..... ). Next to that you want to manage your transactions at your service/business level (that is your unit of work that needs to be transactional), which would make managing transaction/exception handling leak into your service layer where it doesn't really belong, next to that you start to pass around connections (or sessions/entitymanagers in this case) to have multiple db calls participate in the same transaction.

    Comment


    • #3
      thank you for your detailed answer! :-)

      So its possible to create mySQL tables with hibernate and thats why its possible to use myISAMDialecet, but its never possible to write into a database with hibernate without using transactions?

      Additional, I also reread through the source I mentioned again and I found this:

      Many application developers think they can talk to a database outside of a transaction. This obviously isnít possible; no SQL statement can be send to a database outside of a database transaction. The term nontransactional data access means there are no explicit transaction boundaries, no system transaction, and that the behavior of data access is that of the autocommit mode. It doesnít mean no physical database transactions are involved.
      I think, I understand better now... I somehow overread it.
      Again, thank you! :-)

      Comment

      Working...
      X