I read up on the JPA lifecycle events last week. In my opinion, they
have some shortcomings. Some of these may not apply to the specific
Cayenne implementation of JPA listeners. (In fact, I'd hope none of
these would be insurmountable using Cayenne.)
1) These events are per-object and provide no reference to the current
persistent unit (DataContext). Your entity instance might get events
from all persistent units committing a change. You won't know what
persistent unit to append new audit log inserts.
2) Because they are per-event, there is a much greater performance hit
-- several callbacks per entity instance. If you need both old
values and new values, you will have to monitor both the pre- and
post- events.
3) JPA states that no queries can be executed at this point. So if
you want to create audit logs in the same transaction, you'll have to
figure out a way to delay those inserts until after the current commit
finishes but before the transaction commits.
4) JPA states that a new+update event and an update+delete event may
not execute the update event listener.
On 10/2/06, Aristedes Maniatis <ar..sh.com.au> wrote:
> On 9/30/06, Jeff de Vries <jdevrie..frog.com> wrote:
>
> >> What I'm *really* trying to do is that we have about 15-20 different
> >> types of alerts, and a bunch of rules that specify some additional
> >> processing that needs to take place when certain types of alerts are
> >> generated. Rather than scatter the rules around the umpteen
> >> different
> >> places alerts are created, I thought I'd be "clever" and put all the
> >> rule processing stuff in one place, looking at the alerts as they get
> >> written out. So, as a complete workaround, I could just go add the
> >> rules to the umpteen different places the alerts are getting
> >> generated.
> >> Or, if there was a convenient place to hook some "aspect-oriented"
> >> programming stuff (which is what I guess I'm doing), like a
> >> Alert.onSave(), that would work too.
>
> Actually support to do exactly this is now built into Cayenne 3.0 and
> we are using it in production. It was added only in the last
> fortnight, but is working really well.
>
> http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
>
> I think it will do exactly what you need.
>
>
> As for auditing, I wonder whether this callback work now makes the
> auditing approach redundant? It appears that the callbacks are a more
> general implementation of what Mike has done and might be able to be
> used for his auditing requirements.
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
>
>
This archive was generated by hypermail 2.0.0 : Tue Oct 03 2006 - 12:31:52 EDT