Hibernate version: 3 rc1

Hi, sorry for the length of this post, this problem needs a little explaining.

I understand that the EventListener framework is in place to allow developers to implement their own structure for parts of the Hibernate persistence mechanism.

In our situation we have a very large and complicated domain model in memory with upto 25,000+ objects. We are using Hibernate in a transaction bound manner with auto-flush on as we need to run complex queries that we would like the db to bare the brunt of (and we don't want any stale data or to miss any data that has changed in the cache). We are experiencing performance problems with the auto flush that runs prior to each finder call as it is processing every entity in the cache to determine if its dirty and we call a lot of finders in this particular transaction.

Our initial solution was that we actually have all the required information at hand to tell Hibernate's flush mechanism exactly which entities and their properties are dirty when the flush occurs as we can easily record this information as the transaction progresses due to our wrapping of the hibernate persisted objects.

However there are a couple of problems we have come across:

1) The default implementions of the EventListeners (DefaultFlushEntityEventListener etc.) have lots of private methods and references to protected classes which means that we can't easily extend these listeners to alter the behaviour, I was under the impression that these classes were there to be extended? Is this area going to be changed in future revisions of Hibernate to facilitate extending these EventListeners?

2) I eventually copied down all the private methods required down into our implementation of the AutoFlushEventListener and implemented our own version of the flushEntities method from AbstractFlushingEventListener. This simply skipped over any entities that we knew hadn't changed and didn't need syncing (i.e. didn't generate a FlushEntityEvent for them). However, shortly after a flush, collections started failing with NullPointerException in DefaultInitializeCollectionEventListener.initializeCollectionFromCache where the persister for the collection did not exist. Looking at the onFlushEntity method in the DefaultFlushEntityEventListener seemed to show other work happening regarding collections that seemed to need to be run on all entities regardless of whether they were dirty or not, is this the case, if so what is it doing? Is it possible to seperate out these chunks of work?

regards,
Mike

Certainly the events are new functionality and yes they are meant to be an extension point.

That being said, all the use-cases people would like to use custom listeners is be no means a complete picture.

If you have something specific you'd like to see, then by all means enter a feature request into JIRA. And I don't mean "make all default listener methods public" ;)

Okay, I have entered a request, marked it as an improvement, reference is HHH-287. Have you any information regarding my second question on what is happening r.e. collections in the onFlushEntityMethod in the DefaultFlushEntityEventListener?