[transfer-dev] Re: Lazy Loading Question
Okay yes, turning on debug shows that the gain is very small. Absolutely no point in what I was trying to do. Having sensible indexes helps though :-) Thanks Mark (again!). 2009/7/1 Andrew Myers am2...@gmail.com Doesn't the lazy one need to do more queries making it slower? Or is the end result much the same? 2009/7/1 Mark Mandel mark.man...@gmail.com Why not just make it lazy all the time? Seems to me like you're just doubling your effort from not much gain. Mark On Wed, Jul 1, 2009 at 3:45 PM, Andrew am2...@gmail.com wrote: Is doing this a bad idea? object name=Thingy table=thingy sequence=THINGY_KEY_SEQ id name=id type=numeric column=key_num/ property name=a type=string column=a/ onetomany name=AnotherThiny lazy=true link to=thingies.AnotherThingy column=another_thingy_id/ collection type=array order property=thingyNumber order=asc/ /collection /onetomany /object object name=PopulatedThingy table=thingy sequence=THINGY_KEY_SEQ id name=id type=numeric column=key_num/ property name=a type=string column=a/ . onetomany name=AnotherThingy lazy=false link to=thingies.AnotherThingy column=another_thingy_id/ collection type=array order property=thingyNumber order=asc/ /collection /onetomany /object So if I want to use lazy loading I use the Thingy object, but if I want to get a fully populated object I use the PopulatedThingy object. It works, but is it good practice? -- 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: Stack Overflow Relationships?
Yes it looks like a, it's a cascadeSave(), and it's also going through the AOP Transaction stuff like whostheJBoss guessed. I'm not entirely sure though since I'm losing the rest of the trace. It's saving a Transaction with Attendees in it. And I don't think so you can get back to the original object. Here's the relevant relationships I think: Transaction onetomany Attendee. Event onetomany Package. Package onetomany Attendee. Attendee manytomany ScheduleItem. Event onetomany Track. Track onetomany Topic. Topic manytoone ScheduleItem. Topic manytomany Attendee. This doesn't make any sense either since it's saving new Attendees and shouldn't even be looking at ScheduleItems or something that would have a parent topic. - Elliott On Jun 30, 2:41 pm, Mark Mandel mark.man...@gmail.com wrote: It looks like a stack overflow is occuring in a cascade operations (or more specifically in the ObjectTreeWalker)... which is totally weird because there are check in there to avoid this kind of thing, that and unit tests to test it. I'm going to assume it's a cascadeSave() call that is causing the issue - is there any recursion in the relationship, i.e. can you get back to the original object? Mark On Tue, Jun 30, 2009 at 6:43 PM, Elliott Sprehn espr...@gmail.com wrote: I'm seeing a stack overflow from inside Transfer 1.1 but all the relevant relationships are lazy so it doesn't make any sense. This is the Transfer.xml: http://svn.riaforge.org/saa/trunk/library/com/stellr/config/transfer/... The stack trace is cut off and it doesn't seem to be getting added to the server logs either. I don't see anything in the XML that screams infinite recursion. Does anyone else? The stack repeats with the traverse/traversesingle/traversecollection pattern, here's two traces that fail in different places: ... --~--~-~--~~~---~--~~ 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: Stack Overflow Relationships?
Is the Transaction your object, or is that the Transfer Transaction? Is it possible to break it down to a single index.cfm, and replicate the issue? And then send that through? Mark On Wed, Jul 1, 2009 at 5:34 PM, Elliott Sprehn espr...@gmail.com wrote: Yes it looks like a, it's a cascadeSave(), and it's also going through the AOP Transaction stuff like whostheJBoss guessed. I'm not entirely sure though since I'm losing the rest of the trace. It's saving a Transaction with Attendees in it. And I don't think so you can get back to the original object. Here's the relevant relationships I think: Transaction onetomany Attendee. Event onetomany Package. Package onetomany Attendee. Attendee manytomany ScheduleItem. Event onetomany Track. Track onetomany Topic. Topic manytoone ScheduleItem. Topic manytomany Attendee. This doesn't make any sense either since it's saving new Attendees and shouldn't even be looking at ScheduleItems or something that would have a parent topic. - Elliott On Jun 30, 2:41 pm, Mark Mandel mark.man...@gmail.com wrote: It looks like a stack overflow is occuring in a cascade operations (or more specifically in the ObjectTreeWalker)... which is totally weird because there are check in there to avoid this kind of thing, that and unit tests to test it. I'm going to assume it's a cascadeSave() call that is causing the issue - is there any recursion in the relationship, i.e. can you get back to the original object? Mark On Tue, Jun 30, 2009 at 6:43 PM, Elliott Sprehn espr...@gmail.com wrote: I'm seeing a stack overflow from inside Transfer 1.1 but all the relevant relationships are lazy so it doesn't make any sense. This is the Transfer.xml: http://svn.riaforge.org/saa/trunk/library/com/stellr/config/transfer/. .. The stack trace is cut off and it doesn't seem to be getting added to the server logs either. I don't see anything in the XML that screams infinite recursion. Does anyone else? The stack repeats with the traverse/traversesingle/traversecollection pattern, here's two traces that fail in different places: ... -- 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: Lazy Loading Question
On Jun 30, 11:15 pm, Andrew Myers am2...@gmail.com wrote: Okay yes, turning on debug shows that the gain is very small. Absolutely no point in what I was trying to do. Having sensible indexes helps though :-) Thanks Mark (again!). Lazy loading causes clones to make more queries though which will be slower if you need to do anything complicated with lots of clones. Of course cloning collections doesn't clone the lazy collections so you /gain/ performance there. It's something you'd need to benchmark for your whole application. --~--~-~--~~~---~--~~ 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: Stack Overflow Relationships?
Oooh, it's a weird multithreading issue. Now that is weird... did I miss a var'd variable in the ObjectTreeWalker or something similar. That can be the only thing I can think off the top of my head. I will have a look and see if I can see anything. I tend to varScopeCheck everything, unless that managed to miss something. Mark On Wed, Jul 1, 2009 at 5:42 PM, Elliott Sprehn espr...@gmail.com wrote: Transaction is ours. (I did link the XML ;)) I can't replicate it, it happens randomly. Generally under load. On Jul 1, 12:41 am, Mark Mandel mark.man...@gmail.com wrote: Is the Transaction your object, or is that the Transfer Transaction? Is it possible to break it down to a single index.cfm, and replicate the issue? And then send that through? 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
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.orgwrote: Perhaps I'm doing this totally wrong, but this is what I'm trying... I have a bean called userService: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/ /cffunction 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: cffunction name=saveuser access=public output=false returntype=void cfargument name=user type=any required=true / cfset variables.transfer.save(arguments.user) / cfset variables.transfer.save(arguments.FAKEOBJECT) / /cffunction 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: cfset 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: cfset variables.transfer.save(arguments.user) / cfset variables.transfer.save(arguments.FAKEOBJECT) / 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
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 mark.man...@gmail.com 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.orgwrote: Perhaps I'm doing this totally wrong, but this is what I'm trying... I have a bean called userService: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/ /cffunction 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: cffunction name=saveuser access=public output=false returntype=void cfargument name=user type=any required=true / cfset variables.transfer.save(arguments.user) / cfset variables.transfer.save(arguments.FAKEOBJECT) / /cffunction 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: cfset 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: cfset variables.transfer.save(arguments.user) / cfset variables.transfer.save(arguments.FAKEOBJECT) / 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
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 mark.man...@gmail.com 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.orgwrote: I'm using transaction.execute(userService, saveuser, args) On Jul 1, 4:58 am, Mark Mandel mark.man...@gmail.com 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 mark.man...@gmail.com 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 mark.man...@gmail.com 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: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/ /cffunction 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: cffunction name=saveuser access=public output=false returntype=void cfargument name=user type=any required=true / cfset variables.transfer.save(arguments.user) / cfset variables.transfer.save(arguments.FAKEOBJECT) / /cffunction 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: cfset arguments.transaction.advise(this,saveuser) I have also tried do this inside of my handler instead: transaction = getPlugin(ioc).getBean(TransferTransaction); userService =
[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 mark.man...@gmail.com 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.orgwrote: I'm using transaction.execute(userService, saveuser, args) On Jul 1, 4:58 am, Mark Mandel mark.man...@gmail.com 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 mark.man...@gmail.com 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 mark.man...@gmail.com 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: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/ /cffunction 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: cffunction
[transfer-dev] about Railo
General functionality seems to work fine, but transaction advice of any kind does not actually protect the transaction. It doesn't cause an error, but won't rollback either. This includes both the execute and advise methods. They don't fail, but they don't help. --~--~-~--~~~---~--~~ 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 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 dotfus...@changethings.orgwrote: 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 mark.man...@gmail.com 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.orgwrote: I'm using transaction.execute(userService, saveuser, args) On Jul 1, 4:58 am, Mark Mandel mark.man...@gmail.com 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 mark.man...@gmail.com 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 mark.man...@gmail.com 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: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/ /cffunction 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.
[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 mark.man...@gmail.com 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 dotfus...@changethings.orgwrote: 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 mark.man...@gmail.com 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.orgwrote: I'm using transaction.execute(userService, saveuser, args) On Jul 1, 4:58 am, Mark Mandel mark.man...@gmail.com 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 mark.man...@gmail.com 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 mark.man...@gmail.com 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: bean id=userService class=model.users.userService constructor-arg name=transfer ref bean=Transfer / /constructor-arg constructor-arg name=transaction ref bean=TransferTransaction / /constructor-arg constructor-arg name=userGateway ref bean=userGateway/ /constructor-arg /bean This is the TransferTransaction that I am passing to the constructor on userService: bean id=TransferTransaction factory-bean=ColdboxOCM factory- method=get constructor-arg name=objectKeyvalueTransferTransaction/ value/constructor-arg /bean In the init method of userService I do: cffunction name=init access=public output=false returntype=userService cfargument name=transfer type=transfer.com.Transfer required=true / cfargument name=transaction type=transfer.com.sql.transaction.Transaction required=true / cfargument name=userGateway type=userGateway required=true / cfset variables.transfer = arguments.transfer / cfset variables.userGateway = arguments.userGateway / cfset arguments.transaction.advise(this,saveuser) cfreturn this/
[transfer-dev] Re: simple transaction failing
On Thu, Jul 2, 2009 at 10:43 AM, whostheJBoss dotfus...@changethings.orgwrote: 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 -~--~~~~--~~--~--~---
