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

[Greg Matthews (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1568?page=comments#action_24805 ] 

Greg Matthews commented on HHH-1568:
------------------------------------

Hi Max,

Thanks for the response and for your work on Hibernate. Great product.

I'm just trying to clarify the applicability of <subselect>

I'd appreciate it you can clarify at least one use of <subselect>. I can't see how this feature is useful at all in a real world application if you need to manually evict it to be sure its up to date. Is this what people do?

Thanks,

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