<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]
