[transfer-dev] Re: simple transaction failing
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 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 > 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 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 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: > > > > > > > > > > > > > > > > //do stuff > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 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 met
[transfer-dev] Re: simple transaction failing
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 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 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 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: > > > > > > > > > > > > > > //do stuff > > > > > > > > > > > > > > > > > > > > > > > > > > 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 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 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 t
[transfer-dev] Re: simple transaction failing
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 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 > 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 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: > > > > > > > > > > //do stuff > > > > > > > > > > > > > > > > > > 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 > >wrote: > > > > > I have uploaded the file to the Google Group. > > > > > On Jul 8, 4:21 pm, Mark Mandel 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 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
[transfer-dev] Re: simple transaction failing
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 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 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: > > > > > > > > //do stuff > > > > > > > > > > > > > > > > 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 >wrote: > > > > > > > > > I have uploaded the file to the Google Group. > > > > > On Jul 8, 4:21 pm, Mark Mandel 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 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 > > > > > > > rol
[transfer-dev] Re: simple transaction failing
I may have worked out a nice solution, actually, let me give it a shot... On Jul 11, 7:07 pm, Mark Mandel 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: > > > > //do stuff > > > > > > > > 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 > wrote: > > > > > I have uploaded the file to the Google Group. > > > On Jul 8, 4:21 pm, Mark Mandel 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 > >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 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:
[transfer-dev] Re: simple transaction failing
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 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: > > > > //do stuff > > > > > > > > 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 > wrote: > > > > > I have uploaded the file to the Google Group. > > > On Jul 8, 4:21 pm, Mark Mandel 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 > >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 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 Sof
[transfer-dev] Re: simple transaction failing
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: //do stuff 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 wrote: > > I have uploaded the file to the Google Group. > > On Jul 8, 4:21 pm, Mark Mandel 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 >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 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
[transfer-dev] Re: simple transaction failing
I have uploaded the file to the Google Group. On Jul 8, 4:21 pm, Mark Mandel 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 > 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 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 > >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:
[transfer-dev] Re: simple transaction failing
Okie dokie. On Jul 8, 4:21 pm, Mark Mandel 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 > 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 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 > >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 S
[transfer-dev] Re: simple transaction failing
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 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 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 >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\userSer
[transfer-dev] Re: simple transaction failing
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 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 > 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 F
[transfer-dev] Re: simple transaction failing
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 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 >
[transfer-dev] Re: simple transaction failing
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\
[transfer-dev] Re: simple transaction failing
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 wrote: > > Any thoughts on this? I can repeat this behavior under multiple > configurations. > > On Jul 3, 8:09 pm, whostheJBoss wrote: > > Sorry, here: > > > > http://www.pastey.net/117046 > > > > On Jul 3, 6:21 pm, Mark Mandel 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 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 > 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: > > > > > > > > > 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: > > > > > > > > > > > > > > > > > > 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 wrote: > > > > > > > > > > aha, there you go! :) > > > > > > > > > > Mark > > > > > > > > > > On Thu, Jul 2, 2009 at 6:13 PM
[transfer-dev] Re: simple transaction failing
Any thoughts on this? I can repeat this behavior under multiple configurations. On Jul 3, 8:09 pm, whostheJBoss wrote: > Sorry, here: > > http://www.pastey.net/117046 > > On Jul 3, 6:21 pm, Mark Mandel 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 > > 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 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 > > >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 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: > > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > 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 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 > > > 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 Trans
[transfer-dev] Re: simple transaction failing
Sorry, here: http://www.pastey.net/117046 On Jul 3, 6:21 pm, Mark Mandel 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 > 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 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 > >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 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: > > > > > > > > > > > > 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: > > > > > > > > > > > > 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 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 > > 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 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: > > > > > > > > > >
[transfer-dev] Re: simple transaction failing
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 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 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 >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 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: > > > > > > > > > > > > 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: > > > > > > > > > > > > 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 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 > 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 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: > > > > > > > >
[transfer-dev] Re: simple transaction failing
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 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 > 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 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: > > > > > > > > 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: > > > > > > > > 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 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 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 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 > >
[transfer-dev] Re: simple transaction failing
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 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 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:
> >
> >
> >
> > 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:
> >
> >
> >
> > 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 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 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 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:
> >
> > > > > > > output="false"
> > > > > > > returntype="void">
> > > > > > > required="true" />
> > > > > > > required="true" />
> >
> > > > > > > />
> > > > > > > />
> > > > > > >
> >
> > > > > > > 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,
[transfer-dev] Re: simple transaction failing
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 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:
>
>
>
> 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:
>
>
>
> 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 wrote:
>
> > aha, there you go! :)
>
> > Mark
>
> > On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss
> > 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 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 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:
>
> > > > > > > > > > > returntype="void">
> > > > > > > > > > > />
> > > > > > > > > > > />
>
> > > > > >
> > > > > >
> > > > > >
>
> > > > > > 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
> > >
[transfer-dev] Re: simple transaction failing
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:
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:
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 wrote:
> aha, there you go! :)
>
> Mark
>
> On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss
> 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 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 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:
>
> > > > > > > > > returntype="void">
> > > > >
> > > > >
>
> > > > >
> > > > >
> > > > >
>
> > > > > 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 advi
[transfer-dev] Re: simple transaction failing
aha, there you go! :)
Mark
On Thu, Jul 2, 2009 at 6:13 PM, whostheJBoss 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 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 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:
> >
> > > > > > > returntype="void">
> > > >
> > > >
> >
> > > >
> > > >
> > > >
> >
> > > > 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 wrote:
> > > > > On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss <
> > > > dotfus...@changethings.org>wrote:
> >
> > > > > > Yes, I did that example exactly before, that's what this is based
> on.
> >
> > > > > > So the trace I see that says "weaving advice" the first time,
> that
> > > > > > just means it's modifying the method? Even though I don't see
> that
> > > > > > trace the next time, the advice is still there?
> >
> > > > > Yes. The AOP works by replacing the method inside the CFC with
> another
> > > > one,
> > > > > and then calling the original which it has moved.
> >
> > > > > What platform are you on?
> >
> > > > > Mark
> >
> > > > > --
> > > > > E: mark.man...@gmail.com
> > > > > T:http://www.twitter.com/neurotic
> > > > > W:www.compoundtheory.com
> >
> > > --
> > > E: mark.
[transfer-dev] Re: simple transaction failing
>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 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 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
> > 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:
>
> > > > > returntype="void">
> > >
> > >
>
> > >
> > >
> > >
>
> > > 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 wrote:
> > > > On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss <
> > > dotfus...@changethings.org>wrote:
>
> > > > > Yes, I did that example exactly before, that's what this is based on.
>
> > > > > So the trace I see that says "weaving advice" the first time, that
> > > > > just means it's modifying the method? Even though I don't see that
> > > > > trace the next time, the advice is still there?
>
> > > > Yes. The AOP works by replacing the method inside the CFC with another
> > > one,
> > > > and then calling the original which it has moved.
>
> > > > What platform are you on?
>
> > > > Mark
>
> > > > --
> > > > 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.
[transfer-dev] Re: simple transaction failing
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/a34c465edcd85263
It seems that Railo is failing to rollback, not Transfer.
On Jul 2, 12:38 am, Mark Mandel 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
> 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:
>
> > > returntype="void">
> >
> >
>
> >
> >
> >
>
> > 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 wrote:
> > > On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss <
> > dotfus...@changethings.org>wrote:
>
> > > > Yes, I did that example exactly before, that's what this is based on.
>
> > > > So the trace I see that says "weaving advice" the first time, that
> > > > just means it's modifying the method? Even though I don't see that
> > > > trace the next time, the advice is still there?
>
> > > Yes. The AOP works by replacing the method inside the CFC with another
> > one,
> > > and then calling the original which it has moved.
>
> > > What platform are you on?
>
> > > Mark
>
> > > --
> > > 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
Does Railo not rollback transactions when an error is thrown from the code?
Mark
On Thu, Jul 2, 2009 at 5:35 PM, whostheJBoss 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:
>
> returntype="void">
>
>
>
>
>
>
>
> 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 wrote:
> > On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss <
> dotfus...@changethings.org>wrote:
> >
> >
> >
> > > Yes, I did that example exactly before, that's what this is based on.
> >
> > > So the trace I see that says "weaving advice" the first time, that
> > > just means it's modifying the method? Even though I don't see that
> > > trace the next time, the advice is still there?
> >
> > Yes. The AOP works by replacing the method inside the CFC with another
> one,
> > and then calling the original which it has moved.
> >
> > What platform are you on?
> >
> > Mark
> >
> > --
> > 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
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:
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 wrote:
> On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss
> wrote:
>
>
>
> > Yes, I did that example exactly before, that's what this is based on.
>
> > So the trace I see that says "weaving advice" the first time, that
> > just means it's modifying the method? Even though I don't see that
> > trace the next time, the advice is still there?
>
> Yes. The AOP works by replacing the method inside the CFC with another one,
> and then calling the original which it has moved.
>
> What platform are you on?
>
> Mark
>
> --
> 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss wrote: > > Yes, I did that example exactly before, that's what this is based on. > > So the trace I see that says "weaving advice" the first time, that > just means it's modifying the method? Even though I don't see that > trace the next time, the advice is still there? Yes. The AOP works by replacing the method inside the CFC with another one, and then calling the original which it has moved. What platform are you on? Mark -- 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
Yes, I did that example exactly before, that's what this is based on.
So the trace I see that says "weaving advice" the first time, that
just means it's modifying the method? Even though I don't see that
trace the next time, the advice is still there?
On Jul 1, 2:36 pm, Mark Mandel wrote:
> You don't want to be advising the method on every call. Once the object has
> AOP advice applied to it, it's done. You don't have to do any more work.
>
> The documentation shows a clear example of how to use the
> AOP:http://docs.transfer-orm.com/wiki/Transactions_and_Transfer.cfm#Aspec...
>
> Mark
>
> On Thu, Jul 2, 2009 at 1:47 AM, whostheJBoss
> wrote:
>
>
>
>
>
> > Ok, it's back to giving me problems. I don't know what the issue is
> > here.
>
> > Mark, do you think you can you shoot me over one very simple working
> > example of AOP advice with a service layer in ColdBox? Doesn't have to
> > be anything complicated, just one simple example where the handler
> > calls the service layer, which has one AOP advised method. (that gets
> > advised every time I call that method)
>
> > Basically, I want every time I call getBean("userservice").saveuser
> > (user) for it to be advised.
>
> > The example I gave above sort of works, but only the first call of
> > saveuser is advised because the init method only runs when the bean is
> > created, not every time.
>
> > In my handler I want to do:
>
> > userService = getPlugin("ioc").getBean("userService");
> > user = instance.Transfer.new("users.user");
> > user.setFirstName("test");
> > userService.saveuser(user)
>
> > And have it advised.
>
> > If I do this:
>
> > transaction = getPlugin("ioc").getBean("TransferTransaction");
> > args = structNew();
> > args.user = user;
> > transaction.execute(userService, "saveuser", args);
>
> > I get stack overflow after the first time.
>
> > If I put the advise in the init() method of the service, it only
> > happens once.
>
> > Thanks!!
>
> > On Jul 1, 5:54 am, Mark Mandel wrote:
> > > Should work.. not sure what is going on... the unit tests all pass.
>
> > > What CF platform are you on?
>
> > > Mark
>
> > > On Wed, Jul 1, 2009 at 10:34 PM, whostheJBoss <
> > dotfus...@changethings.org>wrote:
>
> > > > I'm using transaction.execute(userService, "saveuser",
> > > > args)
>
> > > > On Jul 1, 4:58 am, Mark Mandel wrote:
> > > > > Turn on debug on the advise() method, make sure it's wrapping the
> > method
> > > > you
> > > > > expect it to be.
>
> > > > > It will show you in trace
>
> > > > > Mark
>
> > > > > On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss <
> > dotfus...@changethings.org
> > > > >wrote:
>
> > > > > > innoDB
>
> > > > > > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > > > > > You're not using myISAM tables are you?
>
> > > > > > > Mark
>
> > > > > > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss <
> > > > dotfus...@changethings.org
> > > > > > >wrote:
>
> > > > > > > > It's on MySQL 5, and no, this is a clean Transfer, not the
> > modified
> > > > > > > > AOP version.
>
> > > > > > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > > > > > What DB is this on?
>
> > > > > > > > > Is this your modified code? I believe you made significant
> > > > changes to
> > > > > > the
> > > > > > > > > way transaction AOP worked?
>
> > > > > > > > > Mark
>
> > > > > > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > > > > > dotfus...@changethings.org
> > > > > > > > >wrote:
>
> > > > > > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > > > > > trying...
>
> > > > > > > > > > I have a bean called userService:
>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
>
> > > > > > > > > > This is the TransferTransaction that I am passing to the
> > > > > > constructor
> > > > > > > > > > on userService:
>
> > > > > > > > > > > > > factory-
> > > > > > > > > > method="get">
> > > > > > > > > > > > > name="objectKey">TransferTransaction > > > > > > > > > value>
> > > > > > > > > >
>
> > > > > > > > > > In the init method of userService I do:
>
> > > > > > > > > > > output="false"
> > > > > > > > > > returntype="userService">
> > > > > > > > > > > > > > > type="transfer.com.Transfer"
> > > > > > > > > > required="true" />
> > > > > > > > > > > > > > > > > > > type="transfer.com.sql.transaction.Transaction"
> > required="true"
> > > > />
> > > > > > > > > > > > > type="userGateway"
> > > > > > > > > > required="true" />
>
> > > > > > > > > > > arguments.transfer
> > > > />
> > > > > > > > > > > > > arguments.userGateway
> > > > > > />
>
> > > > > > > > > > > > > > > arguments.transaction.advise(
[transfer-dev] Re: simple transaction failing
You don't want to be advising the method on every call. Once the object has
AOP advice applied to it, it's done. You don't have to do any more work.
The documentation shows a clear example of how to use the AOP:
http://docs.transfer-orm.com/wiki/Transactions_and_Transfer.cfm#Aspect_Oriented_Programming
Mark
On Thu, Jul 2, 2009 at 1:47 AM, whostheJBoss wrote:
>
> Ok, it's back to giving me problems. I don't know what the issue is
> here.
>
> Mark, do you think you can you shoot me over one very simple working
> example of AOP advice with a service layer in ColdBox? Doesn't have to
> be anything complicated, just one simple example where the handler
> calls the service layer, which has one AOP advised method. (that gets
> advised every time I call that method)
>
> Basically, I want every time I call getBean("userservice").saveuser
> (user) for it to be advised.
>
> The example I gave above sort of works, but only the first call of
> saveuser is advised because the init method only runs when the bean is
> created, not every time.
>
> In my handler I want to do:
>
> userService = getPlugin("ioc").getBean("userService");
> user = instance.Transfer.new("users.user");
> user.setFirstName("test");
> userService.saveuser(user)
>
> And have it advised.
>
> If I do this:
>
> transaction = getPlugin("ioc").getBean("TransferTransaction");
> args = structNew();
>args.user = user;
> transaction.execute(userService, "saveuser", args);
>
> I get stack overflow after the first time.
>
> If I put the advise in the init() method of the service, it only
> happens once.
>
> Thanks!!
>
> On Jul 1, 5:54 am, Mark Mandel wrote:
> > Should work.. not sure what is going on... the unit tests all pass.
> >
> > What CF platform are you on?
> >
> > Mark
> >
> > On Wed, Jul 1, 2009 at 10:34 PM, whostheJBoss <
> dotfus...@changethings.org>wrote:
> >
> >
> >
> >
> >
> > > I'm using transaction.execute(userService, "saveuser",
> > > args)
> >
> > > On Jul 1, 4:58 am, Mark Mandel wrote:
> > > > Turn on debug on the advise() method, make sure it's wrapping the
> method
> > > you
> > > > expect it to be.
> >
> > > > It will show you in trace
> >
> > > > Mark
> >
> > > > On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss <
> dotfus...@changethings.org
> > > >wrote:
> >
> > > > > innoDB
> >
> > > > > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > > > > You're not using myISAM tables are you?
> >
> > > > > > Mark
> >
> > > > > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss <
> > > dotfus...@changethings.org
> > > > > >wrote:
> >
> > > > > > > It's on MySQL 5, and no, this is a clean Transfer, not the
> modified
> > > > > > > AOP version.
> >
> > > > > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > > > > What DB is this on?
> >
> > > > > > > > Is this your modified code? I believe you made significant
> > > changes to
> > > > > the
> > > > > > > > way transaction AOP worked?
> >
> > > > > > > > Mark
> >
> > > > > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > > > > dotfus...@changethings.org
> > > > > > > >wrote:
> >
> > > > > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > > > > trying...
> >
> > > > > > > > > I have a bean called userService:
> >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> >
> > > > > > > > > This is the TransferTransaction that I am passing to the
> > > > > constructor
> > > > > > > > > on userService:
> >
> > > > > > > > > > > factory-
> > > > > > > > > method="get">
> > > > > > > > >> > name="objectKey">TransferTransaction > > > > > > > > value>
> > > > > > > > >
> >
> > > > > > > > > In the init method of userService I do:
> >
> > > > > > > > > output="false"
> > > > > > > > > returntype="userService">
> > > > > > > > > > > > > type="transfer.com.Transfer"
> > > > > > > > > required="true" />
> > > > > > > > > > > > > > > > > type="transfer.com.sql.transaction.Transaction"
> required="true"
> > > />
> > > > > > > > > > > type="userGateway"
> > > > > > > > > required="true" />
> >
> > > > > > > > > arguments.transfer
> > > />
> > > > > > > > > > > arguments.userGateway
> > > > > />
> >
> > > > > > > > > > > > > arguments.transaction.advise(this,"saveuser")>
> >
> > > > > > > > >
> > > > > > > > >
> >
> > > > > > > > > Now, as far as I'm aware, this should now wrap saveuser
> method
> > > on
> > > > > > > > > userService in a transaction, so that if anything fails
> inside
> > > of a
> > > > > > > > > call to userService's saveuser method then all database
> actions
> > > > > that
> > > > > > > > > happened during the transaction (during the saveuser
> method)
>
[transfer-dev] Re: simple transaction failing
Ok, it's back to giving me problems. I don't know what the issue is
here.
Mark, do you think you can you shoot me over one very simple working
example of AOP advice with a service layer in ColdBox? Doesn't have to
be anything complicated, just one simple example where the handler
calls the service layer, which has one AOP advised method. (that gets
advised every time I call that method)
Basically, I want every time I call getBean("userservice").saveuser
(user) for it to be advised.
The example I gave above sort of works, but only the first call of
saveuser is advised because the init method only runs when the bean is
created, not every time.
In my handler I want to do:
userService = getPlugin("ioc").getBean("userService");
user = instance.Transfer.new("users.user");
user.setFirstName("test");
userService.saveuser(user)
And have it advised.
If I do this:
transaction = getPlugin("ioc").getBean("TransferTransaction");
args = structNew();
args.user = user;
transaction.execute(userService, "saveuser", args);
I get stack overflow after the first time.
If I put the advise in the init() method of the service, it only
happens once.
Thanks!!
On Jul 1, 5:54 am, Mark Mandel wrote:
> Should work.. not sure what is going on... the unit tests all pass.
>
> What CF platform are you on?
>
> Mark
>
> On Wed, Jul 1, 2009 at 10:34 PM, whostheJBoss
> wrote:
>
>
>
>
>
> > I'm using transaction.execute(userService, "saveuser",
> > args)
>
> > On Jul 1, 4:58 am, Mark Mandel wrote:
> > > Turn on debug on the advise() method, make sure it's wrapping the method
> > you
> > > expect it to be.
>
> > > It will show you in trace
>
> > > Mark
>
> > > On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss > >wrote:
>
> > > > innoDB
>
> > > > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > > > You're not using myISAM tables are you?
>
> > > > > Mark
>
> > > > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss <
> > dotfus...@changethings.org
> > > > >wrote:
>
> > > > > > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > > > > > AOP version.
>
> > > > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > > > What DB is this on?
>
> > > > > > > Is this your modified code? I believe you made significant
> > changes to
> > > > the
> > > > > > > way transaction AOP worked?
>
> > > > > > > Mark
>
> > > > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > > > dotfus...@changethings.org
> > > > > > >wrote:
>
> > > > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > > > trying...
>
> > > > > > > > I have a bean called userService:
>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
>
> > > > > > > > This is the TransferTransaction that I am passing to the
> > > > constructor
> > > > > > > > on userService:
>
> > > > > > > > > factory-
> > > > > > > > method="get">
> > > > > > > > > name="objectKey">TransferTransaction > > > > > > > value>
> > > > > > > >
>
> > > > > > > > In the init method of userService I do:
>
> > > > > > > > > > > > > > > returntype="userService">
> > > > > > > > > > > type="transfer.com.Transfer"
> > > > > > > > required="true" />
> > > > > > > > > > > > > > > type="transfer.com.sql.transaction.Transaction" required="true"
> > />
> > > > > > > > > type="userGateway"
> > > > > > > > required="true" />
>
> > > > > > > > > />
> > > > > > > > > arguments.userGateway
> > > > />
>
> > > > > > > > > > > arguments.transaction.advise(this,"saveuser")>
>
> > > > > > > >
> > > > > > > >
>
> > > > > > > > Now, as far as I'm aware, this should now wrap saveuser method
> > on
> > > > > > > > userService in a transaction, so that if anything fails inside
> > of a
> > > > > > > > call to userService's saveuser method then all database actions
> > > > that
> > > > > > > > happened during the transaction (during the saveuser method)
> > will
> > > > be
> > > > > > > > rolled back.
>
> > > > > > > > In my handler I do:
>
> > > > > > > > userService =
> > > > getPlugin("ioc").getBean("userService");
> > > > > > > > user = instance.Transfer.new("users.user");
> > > > > > > > user.setEmail("t...@test.com");
> > > > > > > > user.setPassword("test");
> > > > > > > > user.setAccountType(2);
> > > > > > > > userService.saveuser(user);
>
> > > > > > > > So, this works and the database entry is created.
>
> > > > > > > > However, if I go into my userService and add some bad code in
> > the
> > > > > > > > saveuser method:
>
> > > > > > > > > output="false"
> > > > > > > > returntype="void">
> > > > > > > >
[transfer-dev] Re: simple transaction failing
Well, I've managed to get it working, not sure what was going on.
However, when I run the event that does the create, it traces that it
was advised. However, if I run the event again it does not. So, it
only advises the first time. What could be causing this?
On Jul 1, 5:54 am, Mark Mandel wrote:
> Should work.. not sure what is going on... the unit tests all pass.
>
> What CF platform are you on?
>
> Mark
>
> On Wed, Jul 1, 2009 at 10:34 PM, whostheJBoss
> wrote:
>
>
>
>
>
> > I'm using transaction.execute(userService, "saveuser",
> > args)
>
> > On Jul 1, 4:58 am, Mark Mandel wrote:
> > > Turn on debug on the advise() method, make sure it's wrapping the method
> > you
> > > expect it to be.
>
> > > It will show you in trace
>
> > > Mark
>
> > > On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss > >wrote:
>
> > > > innoDB
>
> > > > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > > > You're not using myISAM tables are you?
>
> > > > > Mark
>
> > > > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss <
> > dotfus...@changethings.org
> > > > >wrote:
>
> > > > > > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > > > > > AOP version.
>
> > > > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > > > What DB is this on?
>
> > > > > > > Is this your modified code? I believe you made significant
> > changes to
> > > > the
> > > > > > > way transaction AOP worked?
>
> > > > > > > Mark
>
> > > > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > > > dotfus...@changethings.org
> > > > > > >wrote:
>
> > > > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > > > trying...
>
> > > > > > > > I have a bean called userService:
>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
>
> > > > > > > > This is the TransferTransaction that I am passing to the
> > > > constructor
> > > > > > > > on userService:
>
> > > > > > > > > factory-
> > > > > > > > method="get">
> > > > > > > > > name="objectKey">TransferTransaction > > > > > > > value>
> > > > > > > >
>
> > > > > > > > In the init method of userService I do:
>
> > > > > > > > > > > > > > > returntype="userService">
> > > > > > > > > > > type="transfer.com.Transfer"
> > > > > > > > required="true" />
> > > > > > > > > > > > > > > type="transfer.com.sql.transaction.Transaction" required="true"
> > />
> > > > > > > > > type="userGateway"
> > > > > > > > required="true" />
>
> > > > > > > > > />
> > > > > > > > > arguments.userGateway
> > > > />
>
> > > > > > > > > > > arguments.transaction.advise(this,"saveuser")>
>
> > > > > > > >
> > > > > > > >
>
> > > > > > > > Now, as far as I'm aware, this should now wrap saveuser method
> > on
> > > > > > > > userService in a transaction, so that if anything fails inside
> > of a
> > > > > > > > call to userService's saveuser method then all database actions
> > > > that
> > > > > > > > happened during the transaction (during the saveuser method)
> > will
> > > > be
> > > > > > > > rolled back.
>
> > > > > > > > In my handler I do:
>
> > > > > > > > userService =
> > > > getPlugin("ioc").getBean("userService");
> > > > > > > > user = instance.Transfer.new("users.user");
> > > > > > > > user.setEmail("t...@test.com");
> > > > > > > > user.setPassword("test");
> > > > > > > > user.setAccountType(2);
> > > > > > > > userService.saveuser(user);
>
> > > > > > > > So, this works and the database entry is created.
>
> > > > > > > > However, if I go into my userService and add some bad code in
> > the
> > > > > > > > saveuser method:
>
> > > > > > > > > output="false"
> > > > > > > > returntype="void">
> > > > > > > > > required="true"
> > > > />
>
> > > > > > > > > />
> > > > > > > > > variables.transfer.save(arguments.FAKEOBJECT)
> > > > />
> > > > > > > >
>
> > > > > > > > Since FAKEOBJECT doesn't exist, it throws an error. However,
> > the
> > > > save
> > > > > > > > right before it worked and stays in the database.
>
> > > > > > > > I was under the impression that this kind of transaction would
> > roll
> > > > > > > > back the first save also when the FAKEOBJECT save failed since
> > they
> > > > > > > > are both advised by this:
>
> > > > > > > > > > > arguments.transaction.advise(this,"saveuser")>
>
> > > > > > > > I have also tried do this inside of my handler instead:
>
> > > > > > > > transaction = getPlugin("ioc").getBean("TransferTransaction");
>
> > > > > > > > userService =
> > > > getPlugin("ioc").getBean("userService");
> > > > > > > >
[transfer-dev] Re: simple transaction failing
Should work.. not sure what is going on... the unit tests all pass.
What CF platform are you on?
Mark
On Wed, Jul 1, 2009 at 10:34 PM, whostheJBoss wrote:
>
> I'm using transaction.execute(userService, "saveuser",
> args)
>
>
>
> On Jul 1, 4:58 am, Mark Mandel wrote:
> > Turn on debug on the advise() method, make sure it's wrapping the method
> you
> > expect it to be.
> >
> > It will show you in trace
> >
> > Mark
> >
> > On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss >wrote:
> >
> >
> >
> >
> >
> > > innoDB
> >
> > > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > > You're not using myISAM tables are you?
> >
> > > > Mark
> >
> > > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss <
> dotfus...@changethings.org
> > > >wrote:
> >
> > > > > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > > > > AOP version.
> >
> > > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > > What DB is this on?
> >
> > > > > > Is this your modified code? I believe you made significant
> changes to
> > > the
> > > > > > way transaction AOP worked?
> >
> > > > > > Mark
> >
> > > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > > dotfus...@changethings.org
> > > > > >wrote:
> >
> > > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > > trying...
> >
> > > > > > > I have a bean called userService:
> >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> >
> > > > > > > This is the TransferTransaction that I am passing to the
> > > constructor
> > > > > > > on userService:
> >
> > > > > > > factory-
> > > > > > > method="get">
> > > > > > >name="objectKey">TransferTransaction > > > > > > value>
> > > > > > >
> >
> > > > > > > In the init method of userService I do:
> >
> > > > > > > > > > > > > returntype="userService">
> > > > > > > > > type="transfer.com.Transfer"
> > > > > > > required="true" />
> > > > > > > > > > > > > type="transfer.com.sql.transaction.Transaction" required="true"
> />
> > > > > > > type="userGateway"
> > > > > > > required="true" />
> >
> > > > > > > />
> > > > > > > arguments.userGateway
> > > />
> >
> > > > > > > > > arguments.transaction.advise(this,"saveuser")>
> >
> > > > > > >
> > > > > > >
> >
> > > > > > > Now, as far as I'm aware, this should now wrap saveuser method
> on
> > > > > > > userService in a transaction, so that if anything fails inside
> of a
> > > > > > > call to userService's saveuser method then all database actions
> > > that
> > > > > > > happened during the transaction (during the saveuser method)
> will
> > > be
> > > > > > > rolled back.
> >
> > > > > > > In my handler I do:
> >
> > > > > > >userService =
> > > getPlugin("ioc").getBean("userService");
> > > > > > >user = instance.Transfer.new("users.user");
> > > > > > >user.setEmail("t...@test.com");
> > > > > > >user.setPassword("test");
> > > > > > >user.setAccountType(2);
> > > > > > >userService.saveuser(user);
> >
> > > > > > > So, this works and the database entry is created.
> >
> > > > > > > However, if I go into my userService and add some bad code in
> the
> > > > > > > saveuser method:
> >
> > > > > > > output="false"
> > > > > > > returntype="void">
> > > > > > > required="true"
> > > />
> >
> > > > > > > />
> > > > > > > variables.transfer.save(arguments.FAKEOBJECT)
> > > />
> > > > > > >
> >
> > > > > > > Since FAKEOBJECT doesn't exist, it throws an error. However,
> the
> > > save
> > > > > > > right before it worked and stays in the database.
> >
> > > > > > > I was under the impression that this kind of transaction would
> roll
> > > > > > > back the first save also when the FAKEOBJECT save failed since
> they
> > > > > > > are both advised by this:
> >
> > > > > > > > > arguments.transaction.advise(this,"saveuser")>
> >
> > > > > > > I have also tried do this inside of my handler instead:
> >
> > > > > > > transaction = getPlugin("ioc").getBean("TransferTransaction");
> >
> > > > > > >userService =
> > > getPlugin("ioc").getBean("userService");
> > > > > > >user = instance.Transfer.new("users.user");
> > > > > > >user.setEmail("t...@test.com");
> > > > > > >user.setPassword("test");
> > > > > > >user.setAccountType(2);
> >
> > > > > > >args = structNew();
> > > > > > >args.user = user;
> > > > > > >transaction.execute(userService, "saveuser",
> args)
> >
> > > > > > > But I get the same results. When there is no bad code
[transfer-dev] Re: simple transaction failing
I'm using transaction.execute(userService, "saveuser",
args)
On Jul 1, 4:58 am, Mark Mandel wrote:
> Turn on debug on the advise() method, make sure it's wrapping the method you
> expect it to be.
>
> It will show you in trace
>
> Mark
>
> On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss
> wrote:
>
>
>
>
>
> > innoDB
>
> > On Jul 1, 4:49 am, Mark Mandel wrote:
> > > You're not using myISAM tables are you?
>
> > > Mark
>
> > > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss > >wrote:
>
> > > > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > > > AOP version.
>
> > > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > > What DB is this on?
>
> > > > > Is this your modified code? I believe you made significant changes to
> > the
> > > > > way transaction AOP worked?
>
> > > > > Mark
>
> > > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> > dotfus...@changethings.org
> > > > >wrote:
>
> > > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> > trying...
>
> > > > > > I have a bean called userService:
>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
>
> > > > > > This is the TransferTransaction that I am passing to the
> > constructor
> > > > > > on userService:
>
> > > > > > > > > > > method="get">
> > > > > > TransferTransaction > > > > > value>
> > > > > >
>
> > > > > > In the init method of userService I do:
>
> > > > > > > > > > > returntype="userService">
> > > > > > > type="transfer.com.Transfer"
> > > > > > required="true" />
> > > > > > > > > > > type="transfer.com.sql.transaction.Transaction" required="true" />
> > > > > > > > > > > required="true" />
>
> > > > > >
> > > > > > > />
>
> > > > > > > arguments.transaction.advise(this,"saveuser")>
>
> > > > > >
> > > > > >
>
> > > > > > Now, as far as I'm aware, this should now wrap saveuser method on
> > > > > > userService in a transaction, so that if anything fails inside of a
> > > > > > call to userService's saveuser method then all database actions
> > that
> > > > > > happened during the transaction (during the saveuser method) will
> > be
> > > > > > rolled back.
>
> > > > > > In my handler I do:
>
> > > > > > userService =
> > getPlugin("ioc").getBean("userService");
> > > > > > user = instance.Transfer.new("users.user");
> > > > > > user.setEmail("t...@test.com");
> > > > > > user.setPassword("test");
> > > > > > user.setAccountType(2);
> > > > > > userService.saveuser(user);
>
> > > > > > So, this works and the database entry is created.
>
> > > > > > However, if I go into my userService and add some bad code in the
> > > > > > saveuser method:
>
> > > > > > > > > > > returntype="void">
> > > > > > > />
>
> > > > > >
> > > > > > > />
> > > > > >
>
> > > > > > Since FAKEOBJECT doesn't exist, it throws an error. However, the
> > save
> > > > > > right before it worked and stays in the database.
>
> > > > > > I was under the impression that this kind of transaction would roll
> > > > > > back the first save also when the FAKEOBJECT save failed since they
> > > > > > are both advised by this:
>
> > > > > > > arguments.transaction.advise(this,"saveuser")>
>
> > > > > > I have also tried do this inside of my handler instead:
>
> > > > > > transaction = getPlugin("ioc").getBean("TransferTransaction");
>
> > > > > > userService =
> > getPlugin("ioc").getBean("userService");
> > > > > > user = instance.Transfer.new("users.user");
> > > > > > user.setEmail("t...@test.com");
> > > > > > user.setPassword("test");
> > > > > > user.setAccountType(2);
>
> > > > > > args = structNew();
> > > > > > args.user = user;
> > > > > > transaction.execute(userService, "saveuser", args)
>
> > > > > > But I get the same results. When there is no bad code in the
> > saveuser
> > > > > > method, it works fine and I see the insert in the database, but
> > when I
> > > > > > add the FAKEOBJECT to produce an error like so:
>
> > > > > >
> > > > > > > />
>
> > > > > > The first save isn't rolled back, the new object stays in the
> > > > > > database.
>
> > > > > > Any ideas why a simple transaction isn't rolling back the database?
>
> > > > > > Thanks!
>
> > > > > --
> > > > > 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
>
> --
[transfer-dev] Re: simple transaction failing
Turn on debug on the advise() method, make sure it's wrapping the method you
expect it to be.
It will show you in trace
Mark
On Wed, Jul 1, 2009 at 9:57 PM, whostheJBoss wrote:
>
> innoDB
>
> On Jul 1, 4:49 am, Mark Mandel wrote:
> > You're not using myISAM tables are you?
> >
> > Mark
> >
> > On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss >wrote:
> >
> >
> >
> >
> >
> > > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > > AOP version.
> >
> > > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > > What DB is this on?
> >
> > > > Is this your modified code? I believe you made significant changes to
> the
> > > > way transaction AOP worked?
> >
> > > > Mark
> >
> > > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss <
> dotfus...@changethings.org
> > > >wrote:
> >
> > > > > Perhaps I'm doing this totally wrong, but this is what I'm
> trying...
> >
> > > > > I have a bean called userService:
> >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
> > > > > This is the TransferTransaction that I am passing to the
> constructor
> > > > > on userService:
> >
> > > > > > > > > method="get">
> > > > > TransferTransaction > > > > value>
> > > > >
> >
> > > > > In the init method of userService I do:
> >
> > > > > > > > > returntype="userService">
> > > > > type="transfer.com.Transfer"
> > > > > required="true" />
> > > > > > > > > type="transfer.com.sql.transaction.Transaction" required="true" />
> > > > > > > > > required="true" />
> >
> > > > >
> > > > > />
> >
> > > > > arguments.transaction.advise(this,"saveuser")>
> >
> > > > >
> > > > >
> >
> > > > > Now, as far as I'm aware, this should now wrap saveuser method on
> > > > > userService in a transaction, so that if anything fails inside of a
> > > > > call to userService's saveuser method then all database actions
> that
> > > > > happened during the transaction (during the saveuser method) will
> be
> > > > > rolled back.
> >
> > > > > In my handler I do:
> >
> > > > >userService =
> getPlugin("ioc").getBean("userService");
> > > > >user = instance.Transfer.new("users.user");
> > > > >user.setEmail("t...@test.com");
> > > > >user.setPassword("test");
> > > > >user.setAccountType(2);
> > > > >userService.saveuser(user);
> >
> > > > > So, this works and the database entry is created.
> >
> > > > > However, if I go into my userService and add some bad code in the
> > > > > saveuser method:
> >
> > > > > > > > > returntype="void">
> > > > > />
> >
> > > > >
> > > > > />
> > > > >
> >
> > > > > Since FAKEOBJECT doesn't exist, it throws an error. However, the
> save
> > > > > right before it worked and stays in the database.
> >
> > > > > I was under the impression that this kind of transaction would roll
> > > > > back the first save also when the FAKEOBJECT save failed since they
> > > > > are both advised by this:
> >
> > > > > arguments.transaction.advise(this,"saveuser")>
> >
> > > > > I have also tried do this inside of my handler instead:
> >
> > > > > transaction = getPlugin("ioc").getBean("TransferTransaction");
> >
> > > > >userService =
> getPlugin("ioc").getBean("userService");
> > > > >user = instance.Transfer.new("users.user");
> > > > >user.setEmail("t...@test.com");
> > > > >user.setPassword("test");
> > > > >user.setAccountType(2);
> >
> > > > >args = structNew();
> > > > >args.user = user;
> > > > >transaction.execute(userService, "saveuser", args)
> >
> > > > > But I get the same results. When there is no bad code in the
> saveuser
> > > > > method, it works fine and I see the insert in the database, but
> when I
> > > > > add the FAKEOBJECT to produce an error like so:
> >
> > > > >
> > > > > />
> >
> > > > > The first save isn't rolled back, the new object stays in the
> > > > > database.
> >
> > > > > Any ideas why a simple transaction isn't rolling back the database?
> >
> > > > > Thanks!
> >
> > > > --
> > > > 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
> >
>
--
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 r
[transfer-dev] Re: simple transaction failing
innoDB
On Jul 1, 4:49 am, Mark Mandel wrote:
> You're not using myISAM tables are you?
>
> Mark
>
> On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss
> wrote:
>
>
>
>
>
> > It's on MySQL 5, and no, this is a clean Transfer, not the modified
> > AOP version.
>
> > On Jul 1, 4:00 am, Mark Mandel wrote:
> > > What DB is this on?
>
> > > Is this your modified code? I believe you made significant changes to the
> > > way transaction AOP worked?
>
> > > Mark
>
> > > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss > >wrote:
>
> > > > Perhaps I'm doing this totally wrong, but this is what I'm trying...
>
> > > > I have a bean called userService:
>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
>
> > > > This is the TransferTransaction that I am passing to the constructor
> > > > on userService:
>
> > > > > > > method="get">
> > > > TransferTransaction > > > value>
> > > >
>
> > > > In the init method of userService I do:
>
> > > > > > > returntype="userService">
> > > > > > > required="true" />
> > > > > > > type="transfer.com.sql.transaction.Transaction" required="true" />
> > > > > > > required="true" />
>
> > > >
> > > >
>
> > > >
>
> > > >
> > > >
>
> > > > Now, as far as I'm aware, this should now wrap saveuser method on
> > > > userService in a transaction, so that if anything fails inside of a
> > > > call to userService's saveuser method then all database actions that
> > > > happened during the transaction (during the saveuser method) will be
> > > > rolled back.
>
> > > > In my handler I do:
>
> > > > userService = getPlugin("ioc").getBean("userService");
> > > > user = instance.Transfer.new("users.user");
> > > > user.setEmail("t...@test.com");
> > > > user.setPassword("test");
> > > > user.setAccountType(2);
> > > > userService.saveuser(user);
>
> > > > So, this works and the database entry is created.
>
> > > > However, if I go into my userService and add some bad code in the
> > > > saveuser method:
>
> > > > > > > returntype="void">
> > > >
>
> > > >
> > > >
> > > >
>
> > > > Since FAKEOBJECT doesn't exist, it throws an error. However, the save
> > > > right before it worked and stays in the database.
>
> > > > I was under the impression that this kind of transaction would roll
> > > > back the first save also when the FAKEOBJECT save failed since they
> > > > are both advised by this:
>
> > > >
>
> > > > I have also tried do this inside of my handler instead:
>
> > > > transaction = getPlugin("ioc").getBean("TransferTransaction");
>
> > > > userService = getPlugin("ioc").getBean("userService");
> > > > user = instance.Transfer.new("users.user");
> > > > user.setEmail("t...@test.com");
> > > > user.setPassword("test");
> > > > user.setAccountType(2);
>
> > > > args = structNew();
> > > > args.user = user;
> > > > transaction.execute(userService, "saveuser", args)
>
> > > > But I get the same results. When there is no bad code in the saveuser
> > > > method, it works fine and I see the insert in the database, but when I
> > > > add the FAKEOBJECT to produce an error like so:
>
> > > >
> > > >
>
> > > > The first save isn't rolled back, the new object stays in the
> > > > database.
>
> > > > Any ideas why a simple transaction isn't rolling back the database?
>
> > > > Thanks!
>
> > > --
> > > 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
You're not using myISAM tables are you?
Mark
On Wed, Jul 1, 2009 at 9:23 PM, whostheJBoss wrote:
>
> It's on MySQL 5, and no, this is a clean Transfer, not the modified
> AOP version.
>
>
> On Jul 1, 4:00 am, Mark Mandel wrote:
> > What DB is this on?
> >
> > Is this your modified code? I believe you made significant changes to the
> > way transaction AOP worked?
> >
> > Mark
> >
> > On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss >wrote:
> >
> >
> >
> >
> >
> > > Perhaps I'm doing this totally wrong, but this is what I'm trying...
> >
> > > I have a bean called userService:
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > > This is the TransferTransaction that I am passing to the constructor
> > > on userService:
> >
> > > > > method="get">
> > > TransferTransaction > > value>
> > >
> >
> > > In the init method of userService I do:
> >
> > > > > returntype="userService">
> > > > > required="true" />
> > > > > type="transfer.com.sql.transaction.Transaction" required="true" />
> > > > > required="true" />
> >
> > >
> > >
> >
> > >
> >
> > >
> > >
> >
> > > Now, as far as I'm aware, this should now wrap saveuser method on
> > > userService in a transaction, so that if anything fails inside of a
> > > call to userService's saveuser method then all database actions that
> > > happened during the transaction (during the saveuser method) will be
> > > rolled back.
> >
> > > In my handler I do:
> >
> > >userService = getPlugin("ioc").getBean("userService");
> > >user = instance.Transfer.new("users.user");
> > >user.setEmail("t...@test.com");
> > >user.setPassword("test");
> > >user.setAccountType(2);
> > >userService.saveuser(user);
> >
> > > So, this works and the database entry is created.
> >
> > > However, if I go into my userService and add some bad code in the
> > > saveuser method:
> >
> > > > > returntype="void">
> > >
> >
> > >
> > >
> > >
> >
> > > Since FAKEOBJECT doesn't exist, it throws an error. However, the save
> > > right before it worked and stays in the database.
> >
> > > I was under the impression that this kind of transaction would roll
> > > back the first save also when the FAKEOBJECT save failed since they
> > > are both advised by this:
> >
> > >
> >
> > > I have also tried do this inside of my handler instead:
> >
> > > transaction = getPlugin("ioc").getBean("TransferTransaction");
> >
> > >userService = getPlugin("ioc").getBean("userService");
> > >user = instance.Transfer.new("users.user");
> > >user.setEmail("t...@test.com");
> > >user.setPassword("test");
> > >user.setAccountType(2);
> >
> > >args = structNew();
> > >args.user = user;
> > >transaction.execute(userService, "saveuser", args)
> >
> > > But I get the same results. When there is no bad code in the saveuser
> > > method, it works fine and I see the insert in the database, but when I
> > > add the FAKEOBJECT to produce an error like so:
> >
> > >
> > >
> >
> > > The first save isn't rolled back, the new object stays in the
> > > database.
> >
> > > Any ideas why a simple transaction isn't rolling back the database?
> >
> > > Thanks!
> >
> > --
> > 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
It's on MySQL 5, and no, this is a clean Transfer, not the modified
AOP version.
On Jul 1, 4:00 am, Mark Mandel wrote:
> What DB is this on?
>
> Is this your modified code? I believe you made significant changes to the
> way transaction AOP worked?
>
> Mark
>
> On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss
> wrote:
>
>
>
>
>
> > Perhaps I'm doing this totally wrong, but this is what I'm trying...
>
> > I have a bean called userService:
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> > This is the TransferTransaction that I am passing to the constructor
> > on userService:
>
> > > method="get">
> > TransferTransaction > value>
> >
>
> > In the init method of userService I do:
>
> > > returntype="userService">
> > > required="true" />
> > > type="transfer.com.sql.transaction.Transaction" required="true" />
> > > required="true" />
>
> >
> >
>
> >
>
> >
> >
>
> > Now, as far as I'm aware, this should now wrap saveuser method on
> > userService in a transaction, so that if anything fails inside of a
> > call to userService's saveuser method then all database actions that
> > happened during the transaction (during the saveuser method) will be
> > rolled back.
>
> > In my handler I do:
>
> > userService = getPlugin("ioc").getBean("userService");
> > user = instance.Transfer.new("users.user");
> > user.setEmail("t...@test.com");
> > user.setPassword("test");
> > user.setAccountType(2);
> > userService.saveuser(user);
>
> > So, this works and the database entry is created.
>
> > However, if I go into my userService and add some bad code in the
> > saveuser method:
>
> > > returntype="void">
> >
>
> >
> >
> >
>
> > Since FAKEOBJECT doesn't exist, it throws an error. However, the save
> > right before it worked and stays in the database.
>
> > I was under the impression that this kind of transaction would roll
> > back the first save also when the FAKEOBJECT save failed since they
> > are both advised by this:
>
> >
>
> > I have also tried do this inside of my handler instead:
>
> > transaction = getPlugin("ioc").getBean("TransferTransaction");
>
> > userService = getPlugin("ioc").getBean("userService");
> > user = instance.Transfer.new("users.user");
> > user.setEmail("t...@test.com");
> > user.setPassword("test");
> > user.setAccountType(2);
>
> > args = structNew();
> > args.user = user;
> > transaction.execute(userService, "saveuser", args)
>
> > But I get the same results. When there is no bad code in the saveuser
> > method, it works fine and I see the insert in the database, but when I
> > add the FAKEOBJECT to produce an error like so:
>
> >
> >
>
> > The first save isn't rolled back, the new object stays in the
> > database.
>
> > Any ideas why a simple transaction isn't rolling back the database?
>
> > Thanks!
>
> --
> 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: simple transaction failing
What DB is this on?
Is this your modified code? I believe you made significant changes to the
way transaction AOP worked?
Mark
On Wed, Jul 1, 2009 at 8:52 PM, whostheJBoss wrote:
>
> Perhaps I'm doing this totally wrong, but this is what I'm trying...
>
> I have a bean called userService:
>
>
>
>
>
>
>
>
>
>
>
>
>
> This is the TransferTransaction that I am passing to the constructor
> on userService:
>
> method="get">
> TransferTransaction value>
>
>
> In the init method of userService I do:
>
> returntype="userService">
> required="true" />
> type="transfer.com.sql.transaction.Transaction" required="true" />
> required="true" />
>
>
>
>
>
>
>
>
>
> Now, as far as I'm aware, this should now wrap saveuser method on
> userService in a transaction, so that if anything fails inside of a
> call to userService's saveuser method then all database actions that
> happened during the transaction (during the saveuser method) will be
> rolled back.
>
> In my handler I do:
>
>userService = getPlugin("ioc").getBean("userService");
>user = instance.Transfer.new("users.user");
>user.setEmail("t...@test.com");
>user.setPassword("test");
>user.setAccountType(2);
>userService.saveuser(user);
>
> So, this works and the database entry is created.
>
> However, if I go into my userService and add some bad code in the
> saveuser method:
>
> returntype="void">
>
>
>
>
>
>
> Since FAKEOBJECT doesn't exist, it throws an error. However, the save
> right before it worked and stays in the database.
>
> I was under the impression that this kind of transaction would roll
> back the first save also when the FAKEOBJECT save failed since they
> are both advised by this:
>
>
>
> I have also tried do this inside of my handler instead:
>
> transaction = getPlugin("ioc").getBean("TransferTransaction");
>
>userService = getPlugin("ioc").getBean("userService");
>user = instance.Transfer.new("users.user");
>user.setEmail("t...@test.com");
>user.setPassword("test");
>user.setAccountType(2);
>
>args = structNew();
>args.user = user;
>transaction.execute(userService, "saveuser", args)
>
> But I get the same results. When there is no bad code in the saveuser
> method, it works fine and I see the insert in the database, but when I
> add the FAKEOBJECT to produce an error like so:
>
>
>
>
> The first save isn't rolled back, the new object stays in the
> database.
>
> Any ideas why a simple transaction isn't rolling back the database?
>
> Thanks!
> >
>
--
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
-~--~~~~--~~--~--~---
