RE: Nesting CFTRANSACTION?
Actually - it seems like also only works up to the top of the current 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: required="No" default="False"> template="DB_#cur.DPDataSource.getType()#\VenueBroker_delete.cfm"> isolation="SERIALIZABLE"> template="DB_#cur.DPDataSource.getType()#\VenueBroker_delete.cfm"> So then, inside my implementation include file, I've got this: false)> curChildren[Cnt].delete(arguments.DeleteChildren, true, true)> It's this line that informs the next call that we're in a transactions: I've tested this and it seems to work. Adding in more finite control of the transaction ( or 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: .Stuff. So I've got something like this: 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? "CFTRANSACTION"))> 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 sens
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: .Stuff. So I've got something like this: 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? "CFTRANSACTION"))> 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
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: .Stuff. So I've got something like this: 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? "CFTRANSACTION"))> 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]
RE: Nesting CFTRANSACTION?
"CFTRANSACTION"))> 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]
RE: Nesting CFTRANSACTION?
I'm probably missing something - but it seems to be that this would require a lot of "outside" knowledge on the part of the CFCs. In other words they would have to know to loop and call and whatnot these entities specially in certain circumstances. I'm trying (but it looks like I'll fail) to make things as DB agnostic as possible. For example I've got a "Venue" component which can be any sort of venue (a building, a park, a room, etc) where a performance or exhibition can take place. This Venue component can have a "Parent" (another Venue Component) and zero or more "Children" (Venue Components contained in a special "VenueCollection" Component). The "user" only deals (for the sake of discussion) with the Venue comoponent - it has methods like new(), save(), delete(), etc. Internally, however the Venue component provides these persistence services via a VenueBroker component - it's this component that does all the work on the DB. It has methods like save(), delete(), etc that take Venue components as arguments. This is working out nicely: the interface only worries about "talking" to the domain components and they don't worry at all about the persistence implementation which is handled by the broker. However when I call "myVenue.delete()" (which internally calls "myVenueBroker.delete(this)") and want to loop through the collection of children and delete them as well I end up with the nesting errors since (I think logically) I'm just calling the delete() methods of the children. Even if I create "entity" components for the broker to call I'm still stuck with this. The way would be to separate the broker and the base component completely - but then the interface code needs to be much more knowledgeable about the way things are working beneath the covers. or so it seems to me. In general I'd rather keep my complexity at the broker level and keep the domain components more "pure" - I'd like the interface to just say "myVenue.delete()" and be done with it rather than have to understand the broker (or, in your case, managers). Perhaps I've modeled this all wrong. Jim Davis -Original Message- From: Christian Cantrell [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 11:37 AM To: CF-Talk Subject: Re: Nesting CFTRANSACTION? On Friday, October 3, 2003, at 01:14 AM, Jim Davis wrote: > 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" The approach I sometimes take is to have a set of components called entities which only worry about a single database table (the relationship between an entity and a database table is usually 1 to 1). For instance, I might have a User entity, and an Orders entity. Each contains functions (and SQL) for inserting, updating and deleting. Calling the deleteUser function of the User entity would often fail because of referential integrity violations if that particular user had any orders. That's where the higher-level components come in: the managers. I create a second package of components called "managers" which handle transactions and "glue" entities together. The User manager component might have a delete function which does the following: 1. Starts a transaction. 2. Deletes all of the users orders. 3. Deletes the user. 4. Commits the transaction. These types of "cascading deletes" can get as complex as you need them to. The key is to keep all your SQL in your entities, and all your transactions in your managers. Christian _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Nesting CFTRANSACTION?
Jim, 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]
Re: Nesting CFTRANSACTION?
On Friday, October 3, 2003, at 01:14 AM, Jim Davis wrote: > 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" The approach I sometimes take is to have a set of components called entities which only worry about a single database table (the relationship between an entity and a database table is usually 1 to 1). For instance, I might have a User entity, and an Orders entity. Each contains functions (and SQL) for inserting, updating and deleting. Calling the deleteUser function of the User entity would often fail because of referential integrity violations if that particular user had any orders. That's where the higher-level components come in: the managers. I create a second package of components called "managers" which handle transactions and "glue" entities together. The User manager component might have a delete function which does the following: 1. Starts a transaction. 2. Deletes all of the users orders. 3. Deletes the user. 4. Commits the transaction. These types of "cascading deletes" can get as complex as you need them to. The key is to keep all your SQL in your entities, and all your transactions in your managers. Christian [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
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]
RE: Nesting CFTRANSACTION?
Thanks Ill look up the patterns youve suggested (although Ill not guarantee to understand them!) but I doubt that Ill be changing anything significant this late in the game. As for the service-oriented CFC could you explain it a bit more? I thought thats what I had in by broker. Basically most of my components are actually comprised of three components working in tandem: a base component (which is used most often and contains the real world implementation) , a collection component (which contains methods for dealing with groups of the base component) and a broker component which contains all persistence-layer implementation logic. It seems like no matter how high up I go if I want to both call a single method for delete of a base component (to prevent code redundancy) and call that method from within itself (to delete a group of related components) Im hosed. ;^) Jim Davis -Original Message- From: Andre Mohamed [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 5:51 AM To: CF-Talk Subject: RE: Nesting CFTRANSACTION? Jim, There are several approaches one can take here. One of those possibilities is to utilize the Composite Design Pattern (google will give you endless examples including: http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns_p.h tml) perhaps in combination with the Strategy Design Pattern to implement the transaction control (again google will help) Another approach, if Composite is not appropriate for your parent-child hierarchy is to allow transaction control to be handled by a service-oriented CFC leaving the finer granular CFCs free to ignore the issues of transactions. After all, once you include the transaction control at the lowest level, it precludes that CFC being used as part of any larger transaction in the future and that includes ones you havent thought of yet. André -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 Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
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 Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Nesting CFTRANSACTION?
Jim, There are several approaches one can take here. One of those possibilities is to utilize the Composite Design Pattern (google will give you endless examples including: http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns_p.h tml) perhaps in combination with the Strategy Design Pattern to implement the transaction control (again google will help) Another approach, if Composite is not appropriate for your parent-child hierarchy is to allow transaction control to be handled by a service-oriented CFC leaving the finer granular CFCs free to ignore the issues of transactions. After all, once you include the transaction control at the lowest level, it precludes that CFC being used as part of any larger transaction in the future and that includes ones you havent thought of yet. André -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 Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
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 Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
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]
