[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1568) <subselect> returns stale data, <synchronize> doesn't evict <subselect> objects from session when session is flushed

[Hashim Kubba (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_30017 ] 

Hashim Kubba commented on HHH-1568:
-----------------------------------

I have opened a discussion under 
Hibernate Forums Index -> Hibernate Users -> SubSelect stale data
I do believe this is a bug 
See http://forum.hibernate.org/viewtopic.php?t=985811 


> <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().

-- 
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