guarantee to understand them!) but I doubt that I’ll be changing
anything significant this late in the game.
As for the “service-oriented” CFC could you explain it a bit more? I
thought that’s 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) I’m 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 CFC’s 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
haven’t 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]
