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 > ID: ?? > LINE: 163 > Template: C:\Program Files (x86)\Apache Software Foundation\Tomcat > 6.0\sites\foo\coldbox\system\coldbox.cfc > ID: ?? > LINE: 58 > Template: C:\Program Files (x86)\Apache Software Foundation\Tomcat > 6.0\sites\foo\Application.cfc > > > On Jul 7, 8:45 pm, Mark Mandel <mark.man...@gmail.com> wrote: > > Actually, thanks for chasing this up. > > > > Fun question for you then - > > > > When you are using transaction.execute() (or even the AOP) within the > > handler, and you intentionally throw an error to try and rollback the > > Transaction, do you see any of the Transfer Transaction elements in the > tag > > context? > > > > I'm wondering of Luis is doing some method trickery in CB with his > handlers. > > > > Mark > > > > On Wed, Jul 8, 2009 at 1:36 PM, whostheJBoss <dotfus...@changethings.org > >wrote: > > > > > > > > > > > > > Any thoughts on this? I can repeat this behavior under multiple > > > configurations. > > > > > On Jul 3, 8:09 pm, whostheJBoss <dotfus...@changethings.org> wrote: > > > > Sorry, here: > > > > > >http://www.pastey.net/117046 > > > > > > On Jul 3, 6:21 pm, Mark Mandel <mark.man...@gmail.com> wrote: > > > > > > > I tried accessing the link.. it's timing out. > > > > > > > I will try it again later. > > > > > > > Mark > > > > > > > On Fri, Jul 3, 2009 at 7:59 PM, whostheJBoss < > > > dotfus...@changethings.org>wrote: > > > > > > > > Ok Mark, I've made a detailed, clear and rich example for you. I > > > > > > didn't want to lose formatting, so I posted it here: > > > > > > > >http://www.oneclickpost.com/post/2OJ7dD0xtN/ > > > > > > > > This explains the exact behavior I am seeing and my configuration > > > > > > attempts that are producing it. > > > > > > > > If I made any typos, I apologize, you should be able to get the > gist > > > > > > of what I'm doing though. > > > > > > > > I had gone to the trouble of writing a separate interceptor that > > > would > > > > > > use execute() from Transfer's transaction to execute the handler > > > > > > method, but I saw the same results as I saw in the post I've just > > > > > > linked to. I also used this interceptor to apply AOP advice, but > > > > > > again, saw the same behavior that the post describes. Something > about > > > > > > advising handler methods or executing them within a transaction > with > > > > > > execute() is funky. > > > > > > > > On Jul 2, 2:30 pm, Mark Mandel <mark.man...@gmail.com> wrote: > > > > > > > The code for AOP transactions would be exactly the same for a > > > ColdBox > > > > > > > handler as it would be for any other CFC, it's just a CFC. > > > > > > > > > Can you send me a reproducible test case, with the DB you are > > > using? > > > > > > > > > Mark > > > > > > > > > On Fri, Jul 3, 2009 at 3:36 AM, whostheJBoss < > > > dotfus...@changethings.org > > > > > > >wrote: > > > > > > > > > > Oh, and this behavior is on both CF8 and Railo. I have tested > for > > > 10 > > > > > > > > hours, worked with multiple people on this and I am certain > this > > > is > > > > > > > > what is happening. > > > > > > > > > > On Jul 2, 10:10 am, whostheJBoss <dotfus...@changethings.org > > > > > wrote: > > > > > > > > > Ok, so I have worked with Micha to resolve this and it > looks > > > like > > > > > > this > > > > > > > > > issue is taken care of. I can now successfully advise my > beans > > > such > > > > > > as > > > > > > > > > service layers, etc. > > > > > > > > > > > So, AOP now works on Railo with Transfer when doing this. > > > > > > > > > > > My issue (which has been the issue all along) is still that > I > > > can't > > > > > > > > > advise an entire handler method in ColdBox. > > > > > > > > > > > My scenario is that I have multiple service layer calls > inside > > > my > > > > > > > > > handler and I want the ENTIRE handler method wrapped in a > > > transaction > > > > > > > > > so in case any of the service layer calls fail they will > all be > > > > > > rolled > > > > > > > > > back. > > > > > > > > > > > I have applied the advice using this: > > > > > > > > > > > <cfset > instance.TransferTransaction.advise(this,"createUser", > > > true)> > > > > > > > > > > > In my onDIComplete method of the handler and I see the > trace > > > that > > > > > > > > > advice has been weaved for createUser, but the transaction > > > simply > > > > > > > > > doesn't work. When I run multiple Transfer actions where > one of > > > them > > > > > > > > > is set up to fail, the others that were called first are > not > > > rolled > > > > > > > > > back, even though they are all wrapped in the advice since > they > > > are > > > > > > > > > all in the handler method and the method has been advised. > Like > > > I > > > > > > > > > said, I see the trace that the advice has been applied to > the > > > method, > > > > > > > > > but for whatever reason it doesn't do anything. > > > > > > > > > > > I have also tried using this: > > > > > > > > > > > <cfset transaction.execute(this, "createUser", arguments)> > > > > > > > > > > > Inside of a proxy method on my handler (doCreateUser). So, > when > > > I > > > > > > call > > > > > > > > > doCreateUser() it executes createUser fine, I see database > > > inserts > > > > > > and > > > > > > > > > it works. However, if one of the inserts inside > createUser() is > > > set > > > > > > up > > > > > > > > > to fail (I call it with bad data from a form, string where > it > > > should > > > > > > > > > be a number), the others are not rolled back even though > the > > > entire > > > > > > > > > method was called using the execute method of the > transaction. > > > > > > > > > > > So, my issue is that I need to be able to advise an entire > > > handler > > > > > > > > > method in ColdBox with Transfer, but when I try this with > > > multiple > > > > > > > > > methods, it doesn't causes any errors, but it doesn't > actually > > > advise > > > > > > > > > the method with a transaction. > > > > > > > > > > > On Jul 2, 1:22 am, Mark Mandel <mark.man...@gmail.com> > wrote: > > > > > > > > > > > > aha, there you go! :) > > > > > > > > > > > > Mark > > > > > > > > > > > > On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss < > > > > > > > > dotfus...@changethings.org>wrote: > > > > > > > > > > > > > From Micha: > > > > > > > > > > > > > "this was a failure (only in version 3.1.0.015 to > 3.1.019) > > > we > > > > > > have > > > > > > > > > > > already fixed, please update to newest release > 3.1.0.020 on > > > > > > > > > > > dev.railo.ch > > > > > > > > > > > or wait for release coming today/tomorrow on www. " > > > > > > > > > > > > > Go figure! > > > > > > > > > > > > > On Jul 2, 12:53 am, whostheJBoss < > > > dotfus...@changethings.org> > > > > > > wrote: > > > > > > > > > > > > I was just coming here to update this thread... > > > > > > > > > > > > > > I posted this to Railo's group: > > > > >http://groups.google.com/group/railo/browse_thread/thread/a34c465edcd. > > > > > > .. > > > > > > > > > > > > > > It seems that Railo is failing to rollback, not > Transfer. > > > > > > > > > > > > > > On Jul 2, 12:38 am, Mark Mandel < > mark.man...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > Does Railo not rollback transactions when an error > is > > > thrown > > > > > > from > > > > > > > > the > > > > > > > > > > > code? > > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > > > On Thu, Jul 2, 2009 at 5:35 PM, whostheJBoss < > > > > > > > > > > > dotfus...@changethings.org>wrote: > > > > > > > > > > > > > > > > Ok, I am seeing the advice work properly now. I > have > > > been > > > > > > > > testing > > > > > > > > > > > > > > vigorously on both CF8 and Railo 3.1.017 > > > > > > > > > > > > > > > > Here is what I have discovered: > > > > > > > > > > > > > > > > Transaction advise on Railo traces this: > > > > > > > > > > > > > > > > Weaving Transaction advice on > > > > > > > > model.users.userservice::saveusers() > > > > > > > > > > > > > > > > So it does fire the AOPAdvisor and modifies the > > > method. > > > > > > > > > > > > > > > > I can run my saveusers() method over and over, no > > > problems, > > > > > > no > > > > > > > > stack > > > > > > > > > > > > > > overflow. > > > > > > > > > > > > > > > > Now, in the middle of doing this I wanted to test > if > > > > > > > > transactions > > > > > > > > > > > were > > > > > > > > > > > > > > actually working (if the database would rollback > my > > > insert > > > > > > upon > > > > > > > > > > > > > > failure of something happening inside the advised > > > method), > > > > > > so I > > > > > > > > did > > > > > > > > > > > > > > the following: > > > > > > > > > > > > > > > > I created two user objects which I pass into > > > > > > > > userService.saveusers() > > > > > > > > > > > > > > from my handler with: > > > > > > > > > > > > > > > > getBean("userService").saveusers(user1,user2); > > > > > > > > > > > > > > > > The method looks like this: > > > > > > > > > > > > > > > > <cffunction name="saveusers" > access="public" > > > > > > > > output="false" > > > > > > > > > > > > > > returntype="void"> > > > > > > > > > > > > > > <cfargument name="user1" > type="any" > > > > > > > > required="true" /> > > > > > > > > > > > > > > <cfargument name="user2" > type="any" > > > > > > > > required="true" /> > > > > > > > > > > > > > > > > <cfset > > > > > > variables.transfer.save(arguments.user1) > > > > > > > > /> > > > > > > > > > > > > > > <cfset > > > > > > variables.transfer.save(arguments.user2) > > > > > > > > /> > > > > > > > > > > > > > > </cffunction> > > > > > > > > > > > > > > > > I run this once and see that both are inserted > > > properly. > > > > > > > > > > > > > > > > Now, I want the next transaction to fail for my > test, > > > but > > > > > > only > > > > > > > > after > > > > > > > > > > > > > > user1 has been inserted, so I need it to fail on > > > user2. > > > > > > This > > > > > > > > way, > > > > > > > > > > > > > > since save(arguments.user1) will add a record to > the > > > > > > database > > > > > > > > and is > > > > > > > > > > > > > > inside the same advised transaction as > > > > > > save(arguments.user2), > > > > > > > > then > > > > > > > > > > > > > > when user2 fails the insert of user1 should be > rolled > > > back > > > > > > as > > > > > > > > well > > > > > > > > > > > > > > since they are in the same transaction and > neither > > > should > > > > > > show > > > > > > > > up in > > > > > > > > > > > > > > the database. > > > > > > > > > > > > > > > > So, what I did was have > user1.setPassword("test"); > > > and > > > > > > > > > > > > > > user2.setPassword("testtest"); > > > > > > > > > > > > > > > > My database field for password is VARCHAR(8) so > both > > > are > > > > > > valid > > > > > > > > the > > > > > > > > > > > > > > first time I try to insert. So, after I do the > first > > > insert > > > > > > and > > > > > > > > both > > > > > > > > > > > > > > user1 and user2 work properly and are inserted, I > > > then > > > > > > modified > > > > > > > > my > > > > > > > > > > > > > > database to be VARCHAR(4) for password. So now > the > > > next > > > > > > time I > > > > > > > > call > > > > > > > > > > > > > > saveusers() the save(arguments.user1) should work > and > > > save > > > > > > > > > > > > > > (arguments.user2) should fail since its password > > > field is > > > > > > too > > > > > > > > long. > > > > > > > > > > > > > > > > Both saves are advised in userService.saveUser() > > > inside the > > > > > > > > save > > > > > > > > > > > > > > transaction, so neither should show up when user2 > > > fails. > > > > > > > > > > > > > > > > So, when I do this it does fail and say that the > > > password > > > > > > field > > > > > > > > for > > > > > > > > > > > > > > user2 is too long, but the insert of user1 stays > in > > > the > > > > > > > > database. > > > > > > > > > > > > > > > > So, again, when both users are valid objects, > they > > > both get > > > > > > > > inserted. > > > > > > > > > > > > > > When one of the users contains data that is too > long > > > for > > > > > > the > > > > > > > > database > > > > > > > > > > > > > > field (both after modifying the field or if I try > to > > > insert > > > > > > > > with > > > > > > > > > > > > > > incorrect data initially) then the first user is > > > inserted > > > > > > and > > > > > > > > stays > > > > > > > > > > > in > > > > > > > > > > > > > > the database when it should be rolled back while > the > > > second > > > > > > > > fails. > > > > > > > > > > > > > > > > On ColdFusion 8 the transaction advise works and > > > user1 is > > > > > > > > rolled back > > > > > > > > > > > > > > and doesn't show up in the database when I use > the > > > exact > > > > > > same > > > > > > > > code. > > > > > > > > > > > > > > > > I see on Railo the trace that > userService.saveusers() > > > has > > > > > > been > > > > > > > > > > > > > > advised, but the transaction > > > > > > ... > > > > > > read more ยป > > > > -- > > E: mark.man...@gmail.com > > T:http://www.twitter.com/neurotic > > W:www.compoundtheory.com > > > -- 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 -~----------~----~----~----~------~----~------~--~---
