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#4006080

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006080
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to