Hibernate version: 3.1.3

Code between sessionFactory.openSession() and session.close():
Session hsession = HibernateUtil.openSession();
hsession.flush();
hsession.clear();
HibernateUtil.getSessionFactory().evict(T.class);
t = hsession.createQuery("select t from T as t").list();
System.out.println("T: "+t.size());
Transaction tx = hsession.beginTransaction();
tx.commit();
t = hsession.createQuery("select t from T as t").list();
System.out.println("T: "+t.size());

Name and version of the database you are using:
MySQL 5

Here's the output:
19:19:20,149 INFO [STDOUT] T: 1
19:19:20,149 INFO [STDOUT] T: 0

So, what I'm trying to do is get a list of all rows of Table T. Another application is making changes to table T, and the behavior is not something I understand. When I add a row to table T, it shows up as expected. When I delete a row from Table T, it continued to show up despite everything I've tried to clear out the cache, until I eventually tried transactions. It seems that committing a transaction, even if it does no work, appears to tell Hibernate that it is free to go query the database instead of either cache for the data. I am mystified, and would really like an explanation or a better fix before my application becomes cluttered with dummy transactions.

Refresh and get do not seem well suited for updating collections, as I have to call get on each member and see if it returns NULL.

Is there a better way of forcing Hibernate to get fresh data from the database without this dummy transaction, and why is this dummy transaction solving my problem when flush, evict, and clear are not? Flush and clear should be redundant anyway, my implementation is guaranteeing a fresh openSession.

I also tried this as my query, but changing from Criteria was one of the things I tried to solve it before I got to transactions.

// t = hsession.createCriteria(T.class).list();