Hibernate version: 3.2.5.ga

Code between sessionFactory.openSession() and session.close():

Session session1 = sessionManager.getCurrentSession();

Integer id = (Integer) session1.save( importObject );

session1.flush();

String hql = "DELETE FROM ImportObject";

session1.createQuery( hql ).executeUpdate();

session1.flush();

Session session2 = sessionManager.getCurrentSession();

session2.setCacheMode( CacheMode.IGNORE );

ImportObject o = (ImportObject) session2.get( ImportObject.class, id );

System.out.println( o.getId() ); // = 1 - why not nullpointerexception?

Criteria c = session.createCriteria( ImportObject.class );

System.out.println( c.list().size() ); = 0 - no objects found as expected!

Problem description

This snippet is obviously not my production code but compiled to illustrate the problem:

I have a few objects in my database. I delete all objects with a HQL statement query. After flushing (and even closing) the session, I obtain another session instance and expect the objects to be gone. Still, when I use the session.get - method I can still get hold of an object apparently previously deleted. The number of objects retrieved from a criteria query for all objects is 0 as expected.

Is this expected behaviour? Is the object still present in one of the caching levels? Is it a bug in Hibernate? Hoping for your reply.

best regards,

Lars

This tells me the object is being retrieved from session's cache. You can verify this by calling session.clear() before looking up a deleted object. If that solves the problem you will need to double check if you are really getting a new session object. The reason hql solution is working is that it goes to database, but a get first consults the first and the second level caches.

Let me know how it goes.

Farzad-

You were right. Our HibernateSessionManager implementation is actually reusing Sessions through potentially multiple transactions. As long as we use session crud methods, working on the 1. level cache, as well as read-operations this works fine, but when using HQL deletes this won't affect the 1. level cache and thus entail problems like this one.

I will have to look into how we can implement the open-session-in-view pattern in another way. I guess calling session.clear() in the hibernate dao method itself will have the potential of screwing up the existing implementation.

Never mind