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

[Max Rydahl Andersen (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=all ]
     
Max Rydahl Andersen closed HHH-1568:
------------------------------------

    Resolution: Rejected

No, synchronize does not evict data it is used for determining flushing.

Your unit test is basically just verifying that scope of identity is still guaranteed when you are using <subselect>;
if you want the latest data do a session.refresh(staleObject) or do the evict manually.

> <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
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>  Environment: Oracle 10g, Java 5, Windows,
>     Reporter: Greg Matthews
>  Attachments: SubselectTest.java, subselect_stale_data.log
>
>
> 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