I like that idea better as well. To avoid JTA, just create an in memory producer/consumer queue. The goal being to get the email transfer on its own thread. That way if there are network timeouts or other issues, you can still work transactions. Not as good as a JMS queue of course.
On Wed, May 5, 2010 at 7:50 AM, Mark Derricutt <[email protected]> wrote: > Depends what "this" you mean. Currently there is a global transaction > wrapped around a servlet request ( REST call ) so the rest of the > system/activity (mostly) assumes it's a participant in an implicit > transaction ( the system already uses JTA, but we have no JMS and I'd > rather not set one up if I didn't need to ) so was thinking this would > be easier. > > I'm going to have a go at rewriting it in the morning slightly > different, instead of each "message" being an XAResource instance > itself, just add the message to a list of events keys by Xid on a > single instance of the XAResource, a commit of the Xid would go and > only those keyed for that Xid. > > I suspect this is more "proper" as well. > > -- > Pull me down under... > > On Wed, May 5, 2010 at 11:35 PM, Robert Casto <[email protected]> > wrote: > > Are you running this immediately after the commit of the transaction? > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Robert Casto www.IWantFreeShipping.com Find Amazon Filler Items easily! -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
