anonymous wrote : Don't set your MySQL transaction setting to READ UNCOMMITTED unless you really want to allow dirty reads (do you!?). I think you might've solved the wrong problem...setting READ UNCOMMITTED works because they're running in separate transactions like the previous post said. Exactly. Dirty reads are VERY BAD. Read what I wrote about them in Hibernate in Action / Java Persistence with Hibernate. anonymous wrote : Anybody have suggestions on how might you do this? Most events are processed synchronously by Seam, so you would have to be doing something "funny" to get a different transaction context. Perhaps he has an asynchronous event. Or perhaps he has no transaction at all. Or perhaps the observer method has REQUIRES_NEW. No code, can't tell. anonymous wrote : Can you just annotate observer methods with transaction attributes or is that only for session beans? An observer method can be on a session bean. And even if it is not, you can annotate methods of JavaBean components with transaction attributes in Seam 1.1. But you should not need to do this. The default behavior is to propagate the transaction, for all component types. By the way, another possibility in Seam 1.1.1 is to use an event that is processed after the transaction commit. This is an excellent way to handle refresh of session or application scoped state after the end of a conversation. The booking example uses this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006080#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...