Spring Framework
  1. Spring Framework
  2. SPR-256

Write operations are not allowed in read-only mode - turn your Session into FlushMode.AUTO respectively remove 'readOnly' marker from transaction definition

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      my code runs fine under 1.0.2, but when i changed spring to 1.1rc1,
      it throws "Write operations are not allowed in read-only mode - turn your Session into FlushMode.AUTO respectively remove 'readOnly' marker from transaction definition" exception while i invoke HibernateDaoSupport.save().

        Activity

        Hide
        Juergen Hoeller added a comment -

        This is a new consistency check introduced in Spring 1.1.

        Invoking HibernateTemplate's save/update/delete methods on a Spring-managed Session in FlushMode.NEVER is potentially dangerous: It means that you are:

        • either doing this in a Spring-managed read-only transaction, which will never flush the Hibernate Session, i.e. never flush your save/update/delete calls. The new check makes you aware that you won't persist your changes in that situation.
        • or working with some other thread-bound Session in FlushMode.NEVER, for example the OpenSessionInViewFilter. If you're overriding closeSession there to flush after view rendering, you should override getSession too, setting the Session to FlushMode.AUTO.

        I strongly recommend against the latter, though. If you're using OpenSessionInViewFilter, combine it with middle tier transactions rather than let the filter flush at request completion.

        Juergen

        Show
        Juergen Hoeller added a comment - This is a new consistency check introduced in Spring 1.1. Invoking HibernateTemplate's save/update/delete methods on a Spring-managed Session in FlushMode.NEVER is potentially dangerous: It means that you are: either doing this in a Spring-managed read-only transaction, which will never flush the Hibernate Session, i.e. never flush your save/update/delete calls. The new check makes you aware that you won't persist your changes in that situation. or working with some other thread-bound Session in FlushMode.NEVER, for example the OpenSessionInViewFilter. If you're overriding closeSession there to flush after view rendering, you should override getSession too, setting the Session to FlushMode.AUTO. I strongly recommend against the latter, though. If you're using OpenSessionInViewFilter, combine it with middle tier transactions rather than let the filter flush at request completion. Juergen
        Hide
        Juergen Hoeller added a comment -

        This is intended behavior, just enforcing stricter compliance to the usage pattern than before. Note that you can always use HibernateTemplate.execute with your own HibernateCallback implementation if you want to to work with the raw Hibernate Session, without such consistency checks.

        Juergen

        Show
        Juergen Hoeller added a comment - This is intended behavior, just enforcing stricter compliance to the usage pattern than before. Note that you can always use HibernateTemplate.execute with your own HibernateCallback implementation if you want to to work with the raw Hibernate Session, without such consistency checks. Juergen

          People

          • Assignee:
            Juergen Hoeller
            Reporter:
            yakuu
            Last updater:
            Trevor Marshall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              9 years, 35 weeks, 3 days ago