[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.rt.eclipselink] Re: in memory rollback

using my application level duringDeletePreRemove event

BTW, this is another example where I need to use application level events. The initial idea was to have a closed business model that I can use in the 2-tier application, but also in SOAP and EDIFACT alike exchange, and naturally in webbased applications. But that would require the correct events to be fired in the BM layer or lower.

I still need to examine what events the EM session fires exactly (you suggested that), but I have a problem fitting the EM-event concept into the BM. Suppose the EM indeed fires the correct "duringSavePostMerge" and "duringDeletePreRemove" alike events, then I still do not want to handle those in the application layer, but all must be done in the BM, so I need a way to have a entity react to that.

First I though that I would need to extend all queries that return the entity (that needs to listen to these events) with code to also add that entity as a listener to the EM that the query is executed upon. But when lazy loading comes into play, that won't work.

Another approach is that I maybe could use the "postLoad" event of the entity, and bind it to the EM there (I have code that "automagically" can determine the active EM). I cannot use the constructor to bind newly created objects, because I'm not certain the object will be persisted. So I have to extend the persist method of the EM to also add the entity as a listener. And that is a bit weird; extend the persist method to add listeners. I do not like that. I already have an extended EM to fix JPA/Eclipselink issues, but this is an application concern moving into the persistence layer.

Or I have to that take approach one level up and introduce my own JPA event annotations. That would allow me to cleanly extend the EM, to support the new events. But then the whole new-event-entity-binding thing conceptually should move to the extended EM, and should not rely on the @PostLoad event code of my business model.

Again, I haven't examined the EM events yet, but I also don't have a clear picture on how I can do this correctly.

Tom

BTW: if you are interested in the extensions I made to the EM, I would be pleased to provide the sources for your review.