openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Audit log with OpenJPA
Date Thu, 07 Jul 2011 16:36:30 GMT
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 <jarif@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message