<subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed -------------------------------------------------------------------------------------------------------------------- Key: HHH-1568 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.1.2 Environment: Oracle 10g, Java 5, Windows, Reporter: Greg Matthews Attachments: subselect_stale_data.log, SubselectTest.java Stale data is being returned from a select against a Hibernate class based on a <subselect> element (instead of a table). See detailed log info attached. A flush is occuring againt entities referenced within <synchronize> elements in the <subclass> based class, but a subsequent HQL query executed against the <subclass> based class still returns stale data. The log details show that the <subclass> object is retrieved from session. Our expectation is that it makes sense for Hibernate to automatically evict objects from session when synchronization causes other entities to be flushed -- otherwise, the whole <synchronization> mechanism is useless and you might as well do everything manually via various evict calls. e.g. If I have 2 mapping files, one for Table A, and another for a <subselect> based on Table A (let's call this View_A, then I will declare a <synchonized> element in View_A so that any changes to A are flushed before records from View_A are retrieved. This seems to work ok in that A is flushed when a query against View_A being executed, but subsequent retrieval of View_A gets loaded from Session, and not from the DB like we'd expect. If we manually evict the rows from View_A before executing the HQL query against View_A then up-to-date data is retrieved from View_A. Another strange thing is that if we *query* View_A after editing records from A, then the following message appears.... 12:43:24 DEBUG org.hibernate.engine.ActionQueue.areTablesToUpdated - changes must be flushed to space: A ...but if we *load* a record from View_A then this message above does not appear. I would have thought any attempt to access View_A after updates to A had occurred would trigger a flush to A. Hopefully the flush occurs behind the scenes in all cases, and it's just a case of a missing log message in the case of doing a session.load().