If you're already doing different stuff for the database and XML, can you
push the transaction out to the database? In other words, can you run a
trigger that ondelete cascades the delete to the children?
-Deanna
----- Original Message -----
From: "Jim Davis" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Friday, October 03, 2003 8:57 AM
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
>
> _____
>
> [Todays
> _____
>
> [Todays
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
