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 pr
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
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 make
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, a
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
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
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 transa
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 ac
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 sit
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
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
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:
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 th
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 w
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 late
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
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/2OJ7
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,
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
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
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
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. "
>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 thi
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 wh
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:
>
> Transactio
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
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 advi
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
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_Progr
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 servic
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 o
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, whosth
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
> >
> >
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 wrot
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 belie
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, w
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:
>
>
38 matches
Mail list logo