David Jencks <[EMAIL PROTECTED]> writes: > I recommend an interceptor. As regards transactional behavior, if you > need it completely transactional, send the messages as the setter > invocations go by in the tx context (make sure your interceptor is > after the tx interceptor so the thread gets the right tx).
Awesome! I didn't even look at the Interceptor interface, seems a lot more sane than overriding the JRMPInvoker. If I go this completely transactional route (good because JMSExceptions should cause a rollback) do you think I'll have to muck about with enlisting JMS XASession objects?... guess I have a bit of experimenting to do. > If you only need 95% (??) reliability you can accumulate the messages > in a list in the interceptor, register a synchronization object with > the tx, and send them all (non-transactionally) on > afterCompletion(true) or not if the tx rolls back. Beautiful! I suppose what you meant by 95% reliability is that there's always a chance that a series of interceptions could happen with mixed transaction contexts, one of which may get rolled back. I can't take that risk... accumulating a list of messages and sending them all at once sounds like a good thing, but how can I associate the transaction so only the correct messages are dealt with on afterCompletion? Can I use Transaction as a key to a WeakHashMap? Otherwise I only see one way to do non-transacted messages: a new Synchronization object per Interceptor.invoke, one message at a time. Ahhh, but this way JMSExceptions would go ignored, bad idea :-( > If you want fancier behavior you could encourage me to finish the rule > engine plugin I wrote which works on more or less this principle and > would let you apply fancy rules to deciding whether or not to send the > message. Does your fancy rules engine involve JMS, or how about the "old value" (which I'm not quite sure how I'm going to find)? Thanks for your advice! -- Gerald Turner Email: [EMAIL PROTECTED] Phone: (503) 788-1720 GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
