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 just doesn't roll back. > > > > > > > > > > > Any idea what the caveat with this on Railo is? This is the > > > > only > > > > > > > thing > > > > > > > > > > I believe that isn't working on Railo. > > > > > > > > > > > On Jul 1, 6:52 pm, Mark Mandel <mark.man...@gmail.com> > > wrote: > > > > > > > > > > > On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss < > > > > > > > > > > dotfus...@changethings.org>wrote: > > ... > > 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 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 -~----------~----~----~----~------~----~------~--~---
