[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1725?page=c...
]
Geoffrey De Smet commented on HHH-1725:
---------------------------------------
Adrian: Emmanuel is a hibernate developer and he commented why.
There's a heavy discussion going on at HHH-2763 and I hope that when that's fixed,
my flush problems go away magically too (hey, I can hope, can't I?:)
lazy properties, events and collection xxx was not processed by flush
exception and EJB3 incompatibility
--------------------------------------------------------------------------------------------------------
Key: HHH-1725
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1725
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.0.cr2
Reporter: Tomasz Bech
It is realted to anomaly:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1540
'When using custom event listeners, sometimes you mess with (and initialize) lazy
collections by mistake, which causes CollectionEntry.postFlush(PersistentCollection) to
throw an AssertionFailure'
It is questionable why AT ALL exception is raised in this case!
What is the most important: EJB3 spec is not prohibiting to check/read/ object involved
in the event, so current implementation is agains EJB3 spec.
Events are often used for validation so it is quite probable that the lazy property
(collection) has to be accessed - and when it is lazy and not initialized before the
exception is raised. Why hibernate cannot treat it in nicer way and allow such actions.
One workaround is to not-use-lazy (very bad).
Second workaround: in the code outside flush (not in event) pre-initialize all lazy
properties (in fact simulation of 'not-lazy).
--
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira