Results 1 to 4 of 4

Thread: Hibernate readOnly transactions

  1. #1
    Join Date
    Aug 2004
    Location
    Brisbane, Australia
    Posts
    4

    Default Hibernate readOnly transactions

    I'm using amixture of Hibernate and JCA data sources in a project, and I'm looking at implementing some query functions to the Hibernate Data Source as read-only transactions. It looks to me like the HibernateTransactionManager will optimise things for me nicely setting the flush mode to FLUSH_NEVER, but unless I'm missing something this behaviour isn't available when using the JtaTransactionManager.

    I've looked at extending HibernateDaoSupport to provide a second HibernateTemplate which is set to FLUSH_NEVER for read only dao methods, but I was wondering if anyone else has tried to handle this at all, and if I'm on approaching the problem the best way?

    Cheers,

    Andrew.

  2. #2
    Join Date
    Aug 2004
    Location
    Germany, Magdeburg
    Posts
    279

    Default

    I've never noticed that FLUSH_NEVER has such a effect. But beside that, just another option that pops in my mind is using a diffrent session/sessionFactory configuring it to use a simple HibernateTransactionManager. So all your read only hibernate queries are 'outside' of the scope of the current application transaction.

    Another option would be to check the LOCK option. I am sure there is a never lock option, which is basically the same as an optimistic read only transaction. But I am not that sure, I've never run into such a problem, frankly.


    Regards,

    Martin (Kersten)

  3. #3
    Join Date
    Aug 2004
    Location
    Brisbane, Australia
    Posts
    4

    Default

    Quote Originally Posted by Martin Kersten
    I've never noticed that FLUSH_NEVER has such a effect.
    OK, perhaps I'm misunderstanding something then. My understanding was that a Hibernate read-only transaction would effectively not flush (no need as it doesn't change the state of the cache at all) and potentially gain
    a perfomance benefit as a result.

    Quote Originally Posted by Martin Kersten
    But beside that, just another option that pops in my mind is using a diffrent session/sessionFactory configuring it to use a simple HibernateTransactionManager. So all your read only hibernate queries are 'outside' of the scope of the current application transaction.
    Unfortunately I don't think that will be an option for us, as we will almost certainly have transactions which will need to span both types of data source. Unless I actively code transaction handling, but we wanted to avoid that and use a declaritive approach wherever possible.

    Quote Originally Posted by Martin Kersten
    Another option would be to check the LOCK option. I am sure there is a never lock option, which is basically the same as an optimistic read only transaction.
    Thanks Martin, I'll look into that as well.

    Cheers,

    Andrew (Daws).

  4. #4
    Join Date
    Aug 2004
    Location
    Montréal, Canada
    Posts
    845

    Default

    from Hibernate code:
    Code:
      if ( session.getFlushMode()!=FlushMode.NEVER) session.flush(); 
      try { 
        session.connection().commit(); 
        committed = true; 
        ...
    from Hibernate javadoc
    Code:
    public static final FlushMode NEVER
    The Session is never flushed unless flush() is explicitly called by the application. This mode is very efficient for read only transactions. 
    ...
    Flushing is the process of synchronising the underlying persistent store with persistable state held in memory.
    FlushMode.NEVER allows to implement "readonly transactions". Unless sesion.flush is called, no synchronization will be executed resulting in a potential gain of perfomance.
    Omar Irbouh

    Spring Modules Team
    http://irbouh.blogspot.com/

Similar Threads

  1. Replies: 5
    Last Post: Aug 25th, 2005, 05:37 PM
  2. Loosing my SecureContext
    By sklakken in forum Security
    Replies: 3
    Last Post: Jul 21st, 2005, 01:44 PM
  3. Replies: 0
    Last Post: Jun 21st, 2005, 08:09 AM
  4. Replies: 3
    Last Post: Nov 19th, 2004, 07:16 PM
  5. Replies: 7
    Last Post: Aug 21st, 2004, 03:42 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •