hibernate-issues

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Tomasz B. (JIRA) <no...@at...>]

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

  Components: core  
    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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1725?page=all ]
     
Emmanuel Bernard resolved HHH-1725:
-----------------------------------

    Resolution: Rejected

We've thought about that already, but:
 - the spec does not allows that explicitly, it only pass the given entity
 - it would be quite inefficient to to support it since it would require multiple pre-flush phases

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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Tomasz B. (JIRA) <no...@at...>]

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

Tomasz Bech commented on HHH-1725:
----------------------------------

Spec is not allowing it explicitly because the authors maybe didn't realized that somehow it can be prohibited in implementation (and in case of Hibernate it is only prohibited for lazy properties).

Can you describe more precise why it would be inefficient? 
First of all I don't understand the reason of the exception when collection is not processed - why there is an exception, what it means exactly and how it helps developers? We are thinking currently of commenting the exception, but we have no feeling how dangerous it could be.

And if reading lazy properties in event is prohibited why the exception is not thrown immidiately at the place when happens but at the end of flush (and finding 'wrong' call place is huge job)?

About inefficiency. As I wrote I see in fact one solution - full 'not-lazy' of whole object graph can only work - I cannot imagine more inefficient solution.

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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Emmanuel B. (JIRA) <no...@at...>]

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

Emmanuel Bernard commented on HHH-1725:
---------------------------------------

I can assure the spec authors knew it.

It requires to dirty check all objects apply the listeners, then potentially dirty check once again to see if the user hasn"t change things in the meanwhile (recursively) then dirty check again to apply the DML operations. On big PC this is inefficient

The exception is here cause the flush process is looping through a list of object / collections, if you change that list, things can become undefined.

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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Tomasz B. (JIRA) <no...@at...>]

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

Tomasz Bech commented on HHH-1725:
----------------------------------

Full 'not-lazy' object graph is too tough for the PC farm even :)

The problem could appear ONLY when the objects will be modified and there are no side effects when only reading?
The most common case is reading the main object + lazy properties + collection for validation, no changes in the objects. So maybe it can be set up less strict and allow simple reading, by configuration parameter for example. What do you think?



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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Tomasz B. (JIRA) <no...@at...>]

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

Tomasz Bech commented on HHH-1725:
----------------------------------

I think there is small issue with current implementation (a bug?).
Scenario is:
object A has reference to B (lazy), B has collection C.
when in preInsert a.getB().getAnyProperty() is called the flush is raising exception 'collection b.c was not processed by flush()'.
(it is not rising exception like 'property b was not processed by flush()' - so the problem is only when there is lazy property which has at least ONE collection).

The collection C isn't even accessed, used, etc. The exception is to avoid situation of usage/modififcation of collection, and it isn't the case.
So shouldn't following function :
CollectionEntry:
public void postFlush(PersistentCollection collection) throws HibernateException {
		if ( isIgnore() ) {
			ignore = false;
		}
		else if ( !isProcessed() ) {
			throw new AssertionFailure( "collection [" + collection.getRole() + "] was not processed by flush()" );
		}
		collection.setSnapshot(loadedKey, role, snapshot);
	}

check also if collection was initialized? Like this:

public void postFlush(PersistentCollection collection) throws HibernateException {
		if ( isIgnore() ) {
			ignore = false;
		}
		else if (collection.wasInitialized() && !isProcessed() ) {
			throw new AssertionFailure( "collection [" + collection.getRole() + "] was not processed by flush()" );
		}
		collection.setSnapshot(loadedKey, role, snapshot);
	}

In this case the real (currently prohibited by Hibernate) usage of collections in flush will be reported.


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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Steve B. (JIRA) <no...@at...>]

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

Steve Baker commented on HHH-1725:
----------------------------------

I've been bitten by this too. I have a post update event listener which triggers my own lucene indexing.  This indexing does a deep traversal of the entity children to collect any interesting text to index, however this causes an AssertionFailure as described above.

If I only do a shallow indexing then there is no problem but then I have an incomplete lucene index, which is not ideal.

If this is not going to be fixed then what could be an appropriate workaround?  I'm thinking of having an indexing thread which waits for notification from the post update event listener.

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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Michael S. (JIRA) <no...@at...>]

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

Michael Small commented on HHH-1725:
------------------------------------

Steve:

Have you found a solution to your problem yet?  I'm doing the exact same thing (update event listener for Lucene), and it's really annoying.

Thanks,

Mike

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

>   Components: core
>     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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira