Announcement Announcement Module
Collapse
No announcement yet.
Read only data via Spring + Hibernate Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Read only data via Spring + Hibernate

    Noticed that if I want to read some data and if I do not have a transaction context I will not be able to do so because

    "org.hibernate.HibernateException: No Session found for current thread"

    For reading data , is not required a transaction normally.

    So in order for Spring to manage the session it needs to have a transaction even for read only operations like selects... ?

    Is that not an overhead ?

    PS.I do not want to open and close session manually...so i configure and use @Transaction even for only reading data.

    I read this ibm.com/developerworks/java/library/j-ts1/index.html and it seems @Transaction(readOnly=true) does not really help for this

    Thanks a lot.
    Last edited by csergiu77; Mar 14th, 2012, 04:37 AM.

  • #2
    Any idea ?

    Comment


    • #3
      Originally posted by csergiu77 View Post
      Any idea ?
      *bump*

      I'd love to know how to do this with Hibernate 4 as well

      Comment


      • #4
        readOnly is only a hint and allows hibernate to do some performance tricks (no dirty checks etc.) but that is all there is.

        Spring needs to know where to do resource handling (i.e. open an connection or session) and for that you need to tag a method and to do that you need @Transactional (or another means of specifying the transactional method).

        Regarding the question if it is overhead on the database side (for most database) there always will be a transaction however it is now made explicit by marking a method transactional. So is it overhead could be but is it a problem I never had any problem (performance wise or whatever) with it.

        Comment


        • #5
          Originally posted by Marten Deinum View Post
          Regarding the question if it is overhead on the database side (for most database) there always will be a transaction however it is now made explicit by marking a method transactional. So is it overhead could be but is it a problem I never had any problem (performance wise or whatever) with it.
          Thank you for that explanation, Marten. Would you say that your answer implies that the use of propagation="SUPPORTS" isolation level is no longer practically useful?

          As most people, I came across the "No Session" error while upgrading from Hibernate3, where I could use HibernateTemplate to open and close the Hibernate session for me. In Hibernate4 this is no longer an option. Hence all of my service methods advised with SUPPORTS isolation level transactions no longer had access to a session.

          Are you saying that I should just switch to REQUIRED and be done with it? Even for ref data lookups which will never be updated by the application?

          Yesterday I realized that I can use OpenSessionInViewFilter to keep an open Hibernate session available to my service methods at all times. This allows me to continue using SUPPORTS propagation level, but I am concerned about the possibility of dead locks when multiple users are logged in to my app. Would you say that this is a valid concern, or can I count on HibernateTransactionManager to flush the session and release all locks at the end of all transactions that performed updates?

          Comment


          • #6
            An (open) Session isn't the same as a transaction... You can have multiple transactions on a single session. So using a OpenSessionInViewFilter isn't really a problem in that regard as transactions aren't started by the filter only a session is opened.

            SUPPORTS propagation is only useful if there is already a Session for the current thread (either manually or using the OSIVF) else it doesn't do much (as it will not start a transaction/open a session). Propagation level and the fact that someting is readonly are 2 different things from my perspective but that might be just me.

            HibernateTemplate should be considered deprecated since hibernate 3.0.1 (around 2007) as it doesn't add anything anymore.

            Comment

            Working...
            X