Good question. Personally my thought was that PreUpdateEventListener would be the cleaner way to implement the feature. The Trigger would be written in the same language as your application. Because its ejb, you already depend heavily on the ejb container, so java is already must have.
The problem might be the performance issue. Did you recognize bottlenecks in your applications history facility? (More db roundtrips in comparison to the db internal trigger) Another problem: With all your logik inside your ejb layer, another application working directly with your tables would be able to bypass the history mechanism. So the db trigger would ensure that all updated entries are stored inside the history table. So i think both possibilities got their (dis)advantages. The right technique depends on your usage or im wrong? regards [EMAIL PROTECTED] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934596#3934596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934596 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
