Yeah, I don't like doing anything hack-ish in production. During dev is fine (and fun), but I like a solid solution.
However, I do think what you've suggested will work. I wrote an interceptor to apply advice to handlers and also to run them within execute() but I was having the error catching problem. If I use the same interceptor I can simply wrap that execute in that intercept method in a try / catch and I'll be able to accomplish what I need. Thanks! Sorry this was such a backwards issue, I should have had the sense to see the fatal flaw. I guess that's why you wrote Transfer and I use it :) On Jul 13, 2:49 pm, Mark Mandel <[email protected]> wrote: > I guess if you had to - you could put the try/catch around the > transaction.execute() call. > > That would allow the transaction to roll back, and still allow you to handle > it specific to your handler call. > > Mark > > On Tue, Jul 14, 2009 at 5:40 AM, whostheJBoss > <[email protected]>wrote: > > > > > Normally it would be, but this is a scenario where the user has a > > degree of freedom in doing their insert, and if it fails I still need > > the non-database actions that happened in the handler to go through > > while the database actions are rolled back. > > > Scenario: > > > 1.) user inputs data > > > 2.) handler makes multiple calls to service layers using this data > > that all need to be advised in the same transaction > > > 3.) transactions fail and are rolled back > > > 4.) handler writes data to a file regardless of if transaction is > > rolled back or not (this has to happen after the database calls) > > > 5.) handler sets view and other details and continues as normal > > > So, basically the entire handler needs to be advised for rollback, but > > if the database actions fail it still needs to complete what it was > > doing. > > > What I've done to solve this is create a flag around my method as a > > request variable that tracks whether or not the handler event has been > > run yet this request. Then, on failure I throw to onException which re > > runs the handler event, this time the flag is picked up since the > > handler has already been ran once and the database actions are > > skipped. > > > This works, but is hack-ish. > > > So, I ended up creating a plugin that will do the inserts under advise > > and then has its own onException method. > > > Not what I wanted, but it will have to do. > > > On Jul 12, 5:44 am, Mark Mandel <[email protected]> wrote: > > > I would have thought that a transaction failing would be a pretty extreme > > > error. I.e. it is unexpected, and not something your application logic > > > would be built around. > > > > In which case, a global error handler would seem to be the best fit to > > catch > > > it and provide a nice error message to the client, and report it back to > > > you. > > > > How are you using it? > > > > Mark > > > > On Sun, Jul 12, 2009 at 3:18 PM, whostheJBoss < > > [email protected]>wrote: > > > > > Hey Mark, > > > > > Sorry, the try / catches were something I had been messing with later > > > > on. Anyway, the real issue I guess then, is, how can I avoid throwing > > > > page errors and still be able to handle my transactions? I need the > > > > transaction to fail when an error throws, but still be caught by the > > > > system so that the user doesn't get an ugly message. > > > > > onException doesn't seem to be doing the job... > > > > > On Jul 11, 7:07 pm, Mark Mandel <[email protected]> wrote: > > > > > I'm looking through the code, and I'm seeing that you have a > > try/catch > > > > > inside the Transaction itself. > > > > > > For a transaction to be rolled back, the exception needs to bubble > > out to > > > > > the Transaction code. > > > > > > It's exactly the same as if I did: > > > > > > <cftransaction> > > > > > <cftry> > > > > > //do stuff > > > > > <cfthrow message="something went wrong"> > > > > > > <cfcatch></cfcatch> > > > > > </cftry> > > > > > > </cftransaction> > > > > > > In which case the transaction wouldn't roll back, as you are > > swallowing > > > > the > > > > > error. > > > > > > I had thought this would have been self evident, but I guess I should > > > > have > > > > > been clearer that Transactions only get rolled back when the > > exception is > > > > > thrown. > > > > > > Mark > > > > > > On Thu, Jul 9, 2009 at 1:04 PM, whostheJBoss < > > [email protected] > > > > >wrote: > > > > > > > I have uploaded the file to the Google Group. > > > > > > > On Jul 8, 4:21 pm, Mark Mandel <[email protected]> wrote: > > > > > > > You can just send me a .zip file with a controller and AOP > > applied > > > > etc, > > > > > > you > > > > > > > know ;o) Should be much easier. > > > > > > > > Mark > > > > > > > > On Thu, Jul 9, 2009 at 8:41 AM, whostheJBoss < > > > > [email protected] > > > > > > >wrote: > > > > > > > > > I'll set you up an account on my server for the foo site, I'll > > just > > > > > > > > have you change your host file to have foo.com point to my > > box. > > > > I'll > > > > > > > > put up two handlers, one that uses a service with AOP / execute > > and > > > > > > > > one that uses a handler method. > > > > > > > > > I'll do this later tonight and hit you up off list. > > > > > > > > > On Jul 8, 2:49 pm, Mark Mandel <[email protected]> wrote: > > > > > > > > > Well, it seems to be running through a Transaction.... so > > that is > > > > > > totally > > > > > > > > > bizarre. > > > > > > > > > > I think you will have to send me a test bed. > > > > > > > > > > Mark > > > > > > > > > > On Thu, Jul 9, 2009 at 4:37 AM, whostheJBoss < > > > > > > [email protected] > > > > > > > > >wrote: > > > > > > > > > > > Hey Mark, so I've clarified the problem a bit and posted it > > > > here to > > > > > > > > > > preserve formatting again: > > > > > > > > > > >http://www.oneclickpost.com/post/5kN09YAYEN/ > > > > > > > > > > > Also, here is the tax context you requested. > > > > > > > > > > > What you are seeing here is the tag context when I call the > > > > > > > > > > userService from within my handler method to do the > > inserts. In > > > > > > this > > > > > > > > > > case, the userService itself has no advice applied to it > > and > > > > was > > > > > > not > > > > > > > > > > executed within execute(). It is simply being called from > > > > within > > > > > > the > > > > > > > > > > handler method that is being executed through execute() by > > > > another > > > > > > > > > > method within the handler. So in my handler, I am calling > > > > > > createUsers > > > > > > > > > > () which calls transaction.execute(this, _createUsers, > > > > arguments) > > > > > > > > > > > _createusers() is where the userService call is made. > > > > > > > > > > > So, anything that happens within _createUsers() should be > > > > rolled > > > > > > back. > > > > > > > > > > I have also tried directly calling Transfer within the > > > > > > _createUsers() > > > > > > > > > > method: > > > > > > > > > > > instance.Transfer.save(1user); > > > > > > > > > > instance.Transfer.save(user2); > > > > > > > > > > > But the result is exactly the same. So whether or not I > > call > > > > the > > > > > > bean > > > > > > > > > > (which is not advised or using execute()) it doesn't > > matter, > > > > > > handler > > > > > > > > > > methods when advised or using execute() on another handler > > > > method > > > > > > do > > > > > > > > > > not roll the transaction back when part of it fails and > > > > Transfer > > > > > > > > > > transaction elements do appear in the tag context. > > > > > > > > > > > I typically have been hiding the error with a try/catch, > > but I > > > > > > turned > > > > > > > > > > that off to show you the tag context. Either way, it still > > > > works > > > > > > > > > > improperly and user1 is inserted even when user2 fails. If > > I > > > > have > > > > > > the > > > > > > > > > > try/catch around either the call to the service or the > > direct > > > > > > > > > > Transfer.save() then the transaction is not rolled back, > > but if > > > > I > > > > > > > > > > remove this (to display the error in the browser) then > > user1 is > > > > > > rolled > > > > > > > > > > back when user2 fails. Of course, this is not acceptable, I > > > > don't > > > > > > want > > > > > > > > > > errors on the page. So, the fact that turning off try/catch > > > > causes > > > > > > the > > > > > > > > > > rollback to happen doesn't say much. It just means that the > > > > server > > > > > > is > > > > > > > > > > failing everything when the page throws an exception to the > > > > > > browser. > > > > > > > > > > This happens in both CF8 and Railo. > > > > > > > > > > > Application Execution Exception > > > > > > > > > > Error Type: database : 0 > > > > > > > > > > Error Messages: Data truncation: Data too long for column > > > > > > 'password' > > > > > > > > > > at row 1 > > > > > > > > > > > Tag Context: > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 115 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\QueryExecution.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 376 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\TransferInserter.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 137 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\TransferInserter.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 66 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\TransferInserter.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 210 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\transaction\Transaction.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 81 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\transaction\Transaction.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: 50 > > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > > Foundation\Tomcat > > > > > > > > > > 6.0\sites\foo\transfer\com\sql\TransferInserter.cfc > > > > > > > > > > ID: ?? > > > > > > > > > > LINE: > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" 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/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
