| Yes. But actually <cftransaction> is used if you have more than one SQL
| statement (insert or update) that have to be either all committed or all
| rollback.(It's all or nothing deal)
Well, I have several select/inserts that span several tables that all need
to be run at once. All or nothing .. like you said. There are about 12
queries total. I just wanted to make sure that no other opperations could
be performed on those tables while the transaction was in progress since I
am using a 'manual' incramenting primary key.
| So my question is: should we lock constants or no?
Well, like you said, it depends. I'm not sure anyone really knows the exact
trade-off in processing time .. it's kind-of a "use your best judgement"
type of thing. For example: If you set up a single DSN and set it to an
application variable, you you *might* have to lock it for every single query
you run. This is probably more cumbersome than just setting that same
variable with the Request scope on every single page. But, like you said,
your DSN is not very likely to change throughout the life of your app., so
you could probably get away with not locking it. Personally, I like to lock
ALL refernces to Session, Application, and Server variables (better safe
than sorry), so I would be more inclined to use the Request scope .. even
with 50-100 variables. You can set them all in a <cfscript> block and save
yourself some time, also.
Todd Ashworth
----- Original Message -----
From: "Marius Milosav" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Wednesday, December 06, 2000 9:19 PM
Subject: Re: cftransaction .. single threaded?
| Yes. But actually <cftransaction> is used if you have more than one SQL
| statement (insert or update) that have to be either all committed or all
| rollback.(It's all or nothing deal)
| For a single update or insert statement the table is looked for the time
of
| the transaction by the dbEngine so you don't need the <cftransaction>
around
| it and <cflock> won't have any impact on the database.
|
| While we are talking about locking, I have a question too.
| I understand the need to have exclusive locks when (session(application or
| server) variables are being set. I understand that we need read only locks
| around the same variables when we read them.
|
| I understand that CF doesn't have the notion of constants, but I thought
| that by setting
| <cfset application.constInt = 5> and by never changing it during the
| execution of the application in fact
| (for all practical purposes) we declared a constant.
| It seams that the general agreement among people on the list is that even
in
| those cases we should use readonly locks (or set them up with request
| scope). Which probably is OK but if you have 100 (or more of those) to set
| them up for each page it looks to me like a waste of time (even if very
| small, which probably is less than having 50 readonly locks on each page).
|
| Ben Forta in the August edition of CFDJ said that if you are ABSOLUTELY
| sure that a variable (application,session or server) doesn't change you
can
| leave out the readonly lock.
|
| So my question is: should we lock constants or no?
|
| Marius Milosav
| www.scorpiosoft.com
| It's not about technology, it's about people.
| Virtual Help Desk Demo (VHD)
| www.scorpiosoft.com/vhd/login.cfm
|
|
| ----- Original Message -----
| From: "Todd Ashworth" <[EMAIL PROTECTED]>
| To: "CF-Talk" <[EMAIL PROTECTED]>
| Sent: Wednesday, December 06, 2000 2:34 PM
| Subject: cftransaction .. single threaded?
|
|
| > Is a <cftransaction> block single threaded, or do I have to provide my
own
| > database side locking for it? The docs aren't very clear on this at
all.
| >
| > Todd Ashworth
| >
| >
| >
| >
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
