component. it other words it doesn't work for what we want. ;^)
All in told, for both this and your reasons it seems like
getBaseTagList() is a failure for this purpose.
I ended up going the "hard" way (which actually does work out okay) and
adding a "RecursiveCall" Boolean attribute to my method. So now (a
trimmed down version of) my method looks like this:
<!--- Delete Venue --->
<cffunction name="delete".>
<!--- Invocation arguments --->
<cfargument name="Venue".>
<cfargument name="DeleteChildren".>
<cfargument name="RecursiveCall" type="Boolean"
required="No" default="False">
<!--- Attempt to include the relevant
implementation file based on the DataSource type file --->
<cfif RecursiveCall>
<cfinclude
template="DB_#cur.DPDataSource.getType()#\VenueBroker_delete.cfm">
<cfelse>
<cftransaction action=""> isolation="SERIALIZABLE">
<cfinclude
template="DB_#cur.DPDataSource.getType()#\VenueBroker_delete.cfm">
</cftransaction>
</cfif>
</cffunction>
So then, inside my implementation include file, I've got this:
<!--- Loop over Children and Delete them, if needed --->
<cfif arguments.DeleteChildren>
<cfset curChildren = Venue.getChildren().getVenues(true,
false)>
<cfloop from="1" to="#ArrayLen(curChildren)#" index="Cnt">
<cfset
curChildren[Cnt].delete(arguments.DeleteChildren, true, true)>
</cfloop>
</cfif>
It's this line that informs the next call that we're in a transactions:
<cfset curChildren[Cnt].delete(arguments.DeleteChildren, true, true)>
I've tested this and it seems to work. Adding in more finite control of
the transaction (<cftransaction action="" /> or <cftransaction
action="" />) would be a pain, but the default capability is
all I really need here.
If you ever find a better way, I'm all ears. ;^) I with you - as long
as the isolationlevel doesn't change nesting transactions should be
allowed - with the understanding that the transactions aren't really
"nested" but rather "continuing" the initial transactions.
Jim Davis
-----Original Message-----
From: Matthew Walker [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 04, 2003 7:25 AM
To: CF-Talk
Subject: Re: Nesting CFTRANSACTION?
Yes 6.1. It only didn't work for me when I tried to make a nice function
for the evaluation. It works when I insert the _expression_ directly like
you're doing.
I think MACR could be little kinder to us with this tag and just ignore
nested transactions.
----- Original Message -----
From: Jim Davis
To: CF-Talk
Sent: Saturday, October 04, 2003 1:20 PM
Subject: RE: Nesting CFTRANSACTION?
Actually it shows up in the basetag list for me. I'm on MX 6.1, how
about you?
This is actually the approach I'm taking (and testing right now).
One problem is that CFTRANSACTION, being a structural tag you can't
optionally control the tag outside the content. In other words you
can't do this:
<cfif ListFind(getBaseTagList(), "CFTRANSACTION")>
<cftransaction>
</cfif>
.Stuff.
<cfif ListFind(getBaseTagList(), "CFTRANSACTION")>
</cftransaction>
</cfif>
So I've got something like this:
<cfif ListFind(getBaseTagList(), "CFTRANSACTION")>
<cfinlcude template="AllTheSQLStuff">
<cfelse>
<cftransaction>
<cfinlcude template="AllTheSQLStuff">
</cftransaction>
</cfif>
This seems to be working just fine (at least in 6.1), but it has meant
a
redesign of several of my components.
Jim Davis
-----Original Message-----
From: Matthew Walker [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 6:07 PM
To: CF-Talk
Subject: RE: Nesting CFTRANSACTION?
<cffunction name="IsTransaction" returntype="boolean">
<cfreturn yesnoformat(listfind(getbasetaglist(),
"CFTRANSACTION"))>
</cffunction>
You would think that would be just the thing right? Well doesn't seem
to
work. Cftransaction doesn't show up in the base tag list. In my quick
test
the code used directly seemed to work though. How is it going for you?
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Saturday, 4 October 2003 1:57 a.m.
To: CF-Talk
Subject: RE: Nesting CFTRANSACTION?
Thanks. it's not really an option for me however.
The basic structure of this system is that the broker controls all of
the persistence layer-stuff. If I were to try and have to track I
outside of it all hell would break loose. For example the system
works
perfectly well with both an XML-based file storage mechanism and a SQL
Server 2000 database as the persistence layer - this change occurs
seamlessly via the broker with no implementation changes.
However CFTRANSACTION is needed to maintain SQL Server 2000 integrity
while CFLOCK would be needed to maintain the XML file integrity.
I've actually attempted to replace CFTRANSACTION with a CFLOCK
implementation and live with the idea that the database would be
dedicated to the CF App, but I hate that idea.
My current idea (which I've yet to try) is to attempt to determine and
control my transactions by examining the results of GetBaseTagList().
I'm not sure if it'll work. but does seem possible.
Jim Davis
-----Original Message-----
From: Matthew Walker [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 7:55 AM
To: CF-Talk
Subject: RE: Nesting CFTRANSACTION?
Maybe the simplest answer (certainly one I've adopted in some cases
since CF
has become more sensitive to nested transactions) is to leave it up to
the
implementor of your cfc. Just like it's up to the developer to wrap
cflock
around a cffile.
Matt.
-----Original Message-----
From: Kola Oyedeji [mailto:[EMAIL PROTECTED]
Sent: Friday, 3 October 2003 9:14 p.m.
To: CF-Talk
Subject: RE: Nesting CFTRANSACTION?
One possible solution would be to have a version of the delete method,
which does not wrap the delete in cftransaction, e.g.
deleteNoTransaction(). You could then call this version. I know its
not
ideal as it leads to code duplication and I'm not sure if transactions
can even span cfc calls but its just an idea.
Kola
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: 03 October 2003 06:14
To: CF-Talk
Subject: Nesting CFTRANSACTION?
I'm in a position where a component can have a parent/child
relationship
with other components of the same type.
When I delete a single component, no problem - the method starts a
transaction, deletes the component information from the database,
cleans
up references to it in several join tables and updates a couple of
administrative tables.
When a component has Children I would like to delete them as well in
the
same transaction. The best way to do this, of course, is to loop
through the children and call their "delete()" methods.
However when I do this (as I am) from with the parents delete() method
(making the call sorta recursive-like) I get the error we all know and
love: "Cannot nest CFTRANSACTIONS"
In short I don't want to really nest a transaction (that makes no real
sense) I simply want a way to include all the work in a single
transaction. Some way to determine if I'm in a transaction already
and
not try to start a new one.
I'm trying to find some way to do this, perhaps by catching and using
the nesting error itself - but nothing remotely elegant is presenting
itself.
Any solutions, ideas or workarounds?
Jim Davis
_____
_____
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
