Perhaps you could use a separate PU for your audit logging? That should be safe to use inside of a lifecycle callback.
On Thu, Jul 7, 2011 at 11:36 AM, Bengt Rodehav <be...@rodehav.com> wrote: > Jari, > > Yes an asynchronous queue is definitely an option. I've actually used that > approach before. It makes a lot of sense when trying to achieve high > throughput since the audit logging can then be done on lower priority. > > I was however hoping to be able to use JPA for this since a queue increases > the complexity significantly (also regarding testing). > > Thanks, > > /Bengt > > 2011/7/7 Jari Fredriksson <ja...@iki.fi> > > > 7.7.2011 14:05, Bengt Rodehav kirjoitti: > > > I'm using OpenJPA for persistence and would like to audit log any > changes > > > made to my entities. I serialize the objects to JSON (with Gson) and > > store > > > them in a separate table in the database. Since the audit log needs to > > have > > > the correct id's, the audit logging must take place after the entity > has > > > been persisted. > > > > > > I was hoping I could use the @PostPersist and @PostUpdate life cycle > > > callbacks for this. I do seem to have the right information available > and > > > the serialization works fine but I don't know how I can persist my > audit > > log > > > entries at this point. From what I've read, I'm not allowed to use the > > > entity manager in a "Post" lifecycle callback which of course makes > this > > > hard. > > > > > > What do you recommend? Is there a good place in JPA/OpenJPA where I > > > automatically can trigger the storing of an audit log entry as > described > > > above. Of course I can move this logic up from the persistence layer to > a > > > place where I can first have the entity manager persist my entity and > > then > > > explicitly call another service to do the audit log. However, this is a > > > pretty general mechanism that I would like to have automatic support > for > > in > > > my framework which is why I would like to have it pushed down into the > > > persistence layer. > > > > > > Any ideas? > > > > > > > I have not done anything like this, but some kind of queue and a > > separate processor for that queue might be a solution. > > > > Maybe some message queue? Or a singleton Hashtable containing entries, > > and a separate thread for persisting these to database. > > > > Something like that. > > > > > > > > -- > > > > AWAKE! FEAR! FIRE! FOES! AWAKE! > > FEAR! FIRE! FOES! > > AWAKE! AWAKE! > > -- J. R. R. Tolkien > > > > > -- *Rick Curtis*
