> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of James
> Cook
> Sent: Wednesday, June 13, 2001 9:00 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Audit Trail Support
>
>
> > Really cool stuff! This can be easily implemented in CMP/JAWS since JAWS
> > keeps the old state alive.
> >
> Bill,
>
> Before digging into source, can you answer these questions? We have a need
> to identify which fields have changed in our state objects for an audit
> trail. I am gathering information regarding the "tuned updates" process to
> see if it will give us some direction:
>
Without putting much thought into it, my first gut response to implementing
your audit trail is to write your own PersistenceManager that inherits from
JAWSPersistenceManager. Override JAWSPersistenceManager.storeEntity and
JAWSPersistenceManager.removeEntity and put your audit trail code there.
You'll need to modify standardjboss.xml to put your custom persistence
manager in over jaws.
BTW, why can't the db do this for you?
> 1. How does JAWS keep old state alive?
The code that does tuned updates is in
org.jboss.ejb.plugins.jaws.jdbc.JDBCStoreEntityCommand.java in the method
execute. I thing to note is that the old state is updated every time the
entity is stored.
When is an entity stored?
- if no transaction, after every entity method call
- if in a transaction, when the transaction commits
- (when I put my bug patch in) if in a transaction and a finder method is
called, all entities of the finder's type are stored(but NOT committed!)
that are involved with the current transaction the finder is in.
> 2. Does the mechanism assume that the request to persist an object comes
> back to the same container that served the object?
>
Not positive, but I believe there is one, and only one, specific container
per Entity type. Does that answer your question?
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
