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 <dotfus...@changethings.org>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 <mark.man...@gmail.com> 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 < > dotfus...@changethings.org>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 <mark.man...@gmail.com> 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 < > dotfus...@changethings.org > > > >wrote: > > > > > > > I have uploaded the file to the Google Group. > > > > > > > On Jul 8, 4:21 pm, Mark Mandel <mark.man...@gmail.com> 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 < > > > dotfus...@changethings.org > > > > > >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 <mark.man...@gmail.com> 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 < > > > > > dotfus...@changethings.org > > > > > > > >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: 62 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\transfer\com\sql\SQLManager.cfc > > > > > > > > > ID: ?? > > > > > > > > > LINE: 199 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\transfer\com\Transfer.cfc > > > > > > > > > ID: ?? > > > > > > > > > LINE: 182 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\transfer\com\Transfer.cfc > > > > > > > > > ID: ?? > > > > > > > > > LINE: 105 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\model\users\userService.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: 9 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\config\definitions > > > > > > > > > \model.users.userservice.usersave.aop.transfer > > > > > > > > > ID: ?? > > > > > > > > > LINE: 290 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\handlers\test.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: 89 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\transfer\com\sql\transaction\Transaction.cfc > > > > > > > > > ID: ?? > > > > > > > > > LINE: 420 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\handlers\test.cfc > > > > > > > > > ID: ?? > > > > > > > > > LINE: 445 > > > > > > > > > Template: C:\Program Files (x86)\Apache Software > > > > > > > Foundation\Tomcat > > > > > > > > > 6.0\sites\foo\coldbox\system\controller.cfc > > > > ... > > > > read more ยป > > > -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
