hibernate-issues

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

Session cache is not being invalidated by executeUpdate()
---------------------------------------------------------

         Key: HHH-1808
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.2.0.cr2    
 Environment: Hibernate 3.1.3 and 3.2.0.cr2
MS SQL Server 2000
ehCache
    Reporter: Thomas Boerkel
 Attachments: hibernate.log, src.zip

When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().

Example builds on Hibernate tutorial.

First, we create and then alter an object:
      Long personId = mgr.createAndStorePerson("Vor", "Nach");
      
      Session session = HibernateUtil.getSessionFactory().getCurrentSession();
      session.beginTransaction();
      
      Person person1 = (Person)session.load(Person.class, personId);
      person1.setAge(10);
      session.save(person1);
      session.flush();

Then, in the same session, we execute an update:
      session.createQuery("update Person set age = 20").executeUpdate();

Then, we load() again:
      Person person2 = (Person)session.load(Person.class, personId);
      System.out.println(person2.getAge());
      session.getTransaction().commit();      

This prints 10 instead of 20.

If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
      session = HibernateUtil.getSessionFactory().getCurrentSession();
      session.beginTransaction();
      
      Person person3 = (Person)session.load(Person.class, personId);
      System.out.println(person3.getAge());
      
      session.getTransaction().commit();      

So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:

      for(Object o : session.getStatistics().getEntityKeys()) {
        EntityKey key = (EntityKey) o;
        if(key.getEntityName().equals("events.Person")) {
          session.evict(session.load(key.getEntityName(), key.getIdentifier()));
        }
      }

And this is pretty involved and for sure not fast vor many objects.

The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().

You may say, the current behavior is by design and documented, but I still think, this is a big problem.

Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ]

Thomas Boerkel updated HHH-1808:
--------------------------------

    Attachment: src.zip

Repro

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ]

Thomas Boerkel updated HHH-1808:
--------------------------------

    Attachment: hibernate.log

Logfile

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Christian B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ]
     
Christian Bauer resolved HHH-1808:
----------------------------------

    Resolution: Rejected

This is the documented and standardized behavior of the bulk operations...


> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23225 ] 

Thomas Boerkel commented on HHH-1808:
-------------------------------------

Then at least there should be an overloaded evict() method, that takes for example the name of an entity (in my example, "events.Person"), that would evict all objects from that type.

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23227 ] 

Thomas Boerkel commented on HHH-1808:
-------------------------------------

Sometimes, you have to do "normal" and bulk operations in the same transaction.

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Steve E. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23226 ] 

Steve Ebersole commented on HHH-1808:
-------------------------------------

That or you could follow the best practices for this stuff set forth in both the Hibernate documentation and JPA spec which states not to perform bulk operations (executeUpdate()) from sessions/persistence-contexts already containing state.  I vote the later...

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Emmanuel B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23228 ] 

Emmanuel Bernard commented on HHH-1808:
---------------------------------------

flush()
clear()
executeUpdate()

is the right thing to do to be safe

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1808) Session cache is not being invalidated by executeUpdate()

[Thomas B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23229 ] 

Thomas Boerkel commented on HHH-1808:
-------------------------------------

Thanks for all the information. Still it would be very nice to be able to do:
flush()
clear("events.Person")
createQuery("update Person set age = 20").executeUpdate()

> Session cache is not being invalidated by executeUpdate()
> ---------------------------------------------------------
>
>          Key: HHH-1808
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.1.3 and 3.2.0.cr2
> MS SQL Server 2000
> ehCache
>     Reporter: Thomas Boerkel
>  Attachments: hibernate.log, src.zip
>
>
> When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load().
> Example builds on Hibernate tutorial.
> First, we create and then alter an object:
>       Long personId = mgr.createAndStorePerson("Vor", "Nach");
>       
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person1 = (Person)session.load(Person.class, personId);
>       person1.setAge(10);
>       session.save(person1);
>       session.flush();
> Then, in the same session, we execute an update:
>       session.createQuery("update Person set age = 20").executeUpdate();
> Then, we load() again:
>       Person person2 = (Person)session.load(Person.class, personId);
>       System.out.println(person2.getAge());
>       session.getTransaction().commit();      
> This prints 10 instead of 20.
> If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct:
>       session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       Person person3 = (Person)session.load(Person.class, personId);
>       System.out.println(person3.getAge());
>       
>       session.getTransaction().commit();      
> So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do:
>       for(Object o : session.getStatistics().getEntityKeys()) {
>         EntityKey key = (EntityKey) o;
>         if(key.getEntityName().equals("events.Person")) {
>           session.evict(session.load(key.getEntityName(), key.getIdentifier()));
>         }
>       }
> And this is pretty involved and for sure not fast vor many objects.
> The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate().
> You may say, the current behavior is by design and documented, but I still think, this is a big problem.
> Attaching hibernate.log and src.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira