In almost all my classes, I have two fields called "created by" and "modified by" that store, not suprisingly, the User object that is responsible for creating the object in the first place, and the user that last modified the object.

My question is this: What approach should I take so that these fields get updated on cascading save/update/delete actions?

I see a little bit about an EntityPersister in the documentation, but it isn't clear to me how the persister would know who the current User is.

The DAO object that is saving the root node of the graph certainly knows, and I could write something that would walk the graph and update them, but that seems error prone.

Is there something I'm missing, or a recommended approach for this problem?

That may help
http://www.hibernate.org/318.html

And you do not have to use Asegy, simply assign user to a ThreadLocal variable in a filter/interceptor and use it.

Brr, thread locals like this give me the heebie jeebies. They feel so much like global variables that are doing an end-run around encapsulation. I suppose there isn't much way around it.

They are global variables. While I understand your shiver, I would not suggest dismissing them on that basis. ThreadLocals and InheritableThreadLocals are quite convenient and widely used, just be aware of implications and limitations.

If you are in a managed environment, you could look at attaching the userid to the JTA transaction.

Because I'm in a weblogic environment, I simply used the extention to allows me to set properties against the transaction:


Otherwise, you will have to use straight JTA calls to do exactly what getCurrentSession() does.

You will need to maintain a map of transactions to user ids as you get sessions.
You will also need to add yourself as a listener for the transaction complete events so you can remove the transaction->cuid map entries to keep you map size down and allow GC of the transaction objects.