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
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
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
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
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
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
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
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
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
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.
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:
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
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
13 matches
Mail list logo
