Thanks! I've implemented that. Now I get the occasional your transaction was chosen as the deadlock victim exception, but the message retries and succeeds. I imagine this is because I am running the bus multi-threaded, and two messages dealing with the same row come in at the same time. AFAIK, Rhino ESB's transaction level is Serializable. Shouldn't this prevent transaction deadlocks? I'm afraid I don't know much about transaction isolation levels so maybe I am way off base here.
On Jan 14, 11:17 am, Jason Meckley <[email protected]> wrote: > if you're using NH 3. then just open session(s) when the message arrives and > dispose of the session(s) when the message completes. let system transaction > manage the rest. > > if you're using 2.1 then it's best to manage the nh transaction yourself > because there is a memory leak of the system transaction does not complete. > with rhino.servicebus create a message module to open the session(s) and > begin the transaction(s) when a message arrives. when the message completes > commit or rollback the nh transaction(s) depending on the exception (null or > not) and dispose of the session(s). > > in either case you don't need to think about the system.transaction. having > multiple session factories isn't a issue. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
