> Acknowledged. My (admittedly conservative) approach is to prove that the app
> _doesn't_ need locking rather than the reverse. Don't get me wrong, I'm all
> in favour of
> eliminating both the extra coding burden as well as the overhead. That said,
> the docs
> seem to lean towards locking whe
@ Jason
>Are there Ajax or iframe calls or something that could be making
>updates to that session var for that user at the same time in a
>situation where the order of execution could cause an unexpected value
>to be read back out by the server?
Yup...
>To me, it just seems that you almo
@Jay
Yes, fair enough. Granted that CF doesn't guarantee the order of
execution when processing threads in a request, does the application in
this case really have the possibility of having multiple threads making
sequential changes to that specific session variable (which is
thread-safe to
>Then lock the application scope with a read-only lock, copy the value
>into a local variable, then lock the session scope with an exclusive
>lock, then copy the local variable into the session.
Roger that...
Thanks, Dave & all.
On Mon, Jun 1, 2009 at 16:59, Jay Greer wrote:
>
> @Dave
>
>> What version of CF is this?
>
> CF-8.1
>
>> Is there any likelihood of a race condition with Application.bar?
>
> It's possible, yes.
>
>> If there is the likelihood of a race condition with that variable, do
>> I care? That is, could
@Jason
>Assuming you're on CFMX 7 or 8, you no longer need to LOCK on READ...
Well that's debatable for sure...
http://www.horwith.com/index.cfm/2008/4/28/cflock-explained
http://www.horwith.com/index.cfm/2008/7/17/CFLOCK-further-explained
@Dave
> What version of CF is this?
CF-8.1
> Is there any likelihood of a race condition with Application.bar?
It's possible, yes.
> If there is the likelihood of a race condition with that variable, do
> I care? That is, could the race condition cause an improper value of
> any significance?
> That would work, but it's unnecessary overhead unless you're still on CF 5.
> Virtually all that locking has been handled in MX.
Well, no, that's actually not correct. CF doesn't lock variables
unless you use CFLOCK. It simply doesn't crash if you don't lock them,
as it used to with CF 5 and e
That would work, but it's unnecessary overhead unless you're still on CF 5.
Virtually all that locking has been handled in MX.
~|
Want to reach the ColdFusion community with something they want? Let them know
on the House
>
Is there any reason you can't simply lock the app scope, grab
application variable and put it into a local variable, unlock, lock
session, copy from local var to session var, unlock?
~|
Want to reach the ColdFusion community
Assuming you're on CFMX 7 or 8, you no longer need to LOCK on READ, so if
you're concerned about race conditions on the WRITE, just do:
(timeout can be whatever is appropriate)
~|
Want to reach the ColdFusion community
> Having a brain cramp on this one guys...
>
> How would one approach locking when reading a value from the APPLICATION
> scope and subsequently writing it to the SESSION scope..?
>
> EXAMPLE
> --
>
>
It depends.
What version of CF is this?
Is there any likelihood of a race co
You surround code that needs to be locked with cflock and /cflock
statements. Also you are using a session lock with an application
var. Don't take it wrong but the manual is probably a good place to
go to get a handle on this.
Using Persistent Data and Locking:
http://livedocs.adobe.com/coldfus
The ColdFusion manuals are really good and they are also free. I
recommend looking there for a good description of locking.
-Mike Chabot
On Fri, Dec 19, 2008 at 4:24 PM, Steve LaBadie wrote:
> I am using the Alagad Captcha Component and am not familiar with CFLOCK.
> Is this correct for locking
To ditto what has already been said, but also to clarify: It is not
necessary to lock your shared scope access for the purpose of not obtaining
corrupted reads. i.e. process 1 attempts to read large session variable
while session 2 is writing to it. ColdFusion will take care of that for you
a
Lock to avoid problems with race conditions in the places where these
might be an issue. Many Web applications have places where unhandled
race conditions can be a problem.
-Mike Chabot
On Sun, Dec 7, 2008 at 4:36 PM, Matt Quackenbush <[EMAIL PROTECTED]> wrote:
> In virtually every case, locking
In virtually every case, locking session vars has been completely
unnecessary since CFMX (6.0) came out.
On Sun, Dec 7, 2008 at 3:12 PM, j s <[EMAIL PROTECTED]> wrote:
> When creating session structures is it still necessary to cflock in cf8? I
> think i read somewhere that it was no longer need
Teddy Payne wrote:
> I typically don't make my UUIDs my primary keys are I prefer database to
> perform binary searchings on numbers and 35 character strings.
A UUID/GUID is a number. Its string representation may be a bit funky, but it
is still just a 128 bit number.
Jochem
~~~
Yes, that's the one. It's quite good, although it isn't a TOAD-killer
(but there again what is?).
On 10/8/06, Dave Watts <[EMAIL PROTECTED]> wrote:
> > > Because Oracle has a Free tool now that does a lot of
> > > the same work.
> >
> > What Free tool from Quest does the same thing as TOAD?
>
> I
> > Because Oracle has a Free tool now that does a lot of
> > the same work.
>
> What Free tool from Quest does the same thing as TOAD?
I think James is referring to Oracle's new free SQL Developer:
http://www.oracle.com/technology/software/products/sql/index.html
Dave Watts, CTO, Fig Leaf Sof
-Talk
Subject: Re: locking, I think
That'll work fine.
Out of interest, why can't you get TOAD to manage your Oracle DB? Too
expensive or some other reason? Because Oracle has a Free tool now that does
a lot of the same work.
On 10/7/06, daniel kessler <[EMAIL PROTECTED]> wrote:
>
That'll work fine.
Out of interest, why can't you get TOAD to manage your Oracle DB? Too
expensive or some other reason? Because Oracle has a Free tool now
that does a lot of the same work.
On 10/7/06, daniel kessler <[EMAIL PROTECTED]> wrote:
> alright, I'm gonna try to get the number from DUAL
alright, I'm gonna try to get the number from DUAL and insert that.
I'd like to try triggers, but the last time I tried to make them, I had
problems. We aren't allowed to use a GUI (managing tool) to work with the DB.
Admittedly, I was pretty much a complete novice at the time. So when I have
> scope_identity and @@identity are one type of solution. Primary Keys
that
> are autoincremented are hard to follow soemtimes and are a bit tricky
to
> retrieve sometimes on high transactional systems.
Which is exactly why I prefer Oracle's (and PostgreSQL as well,
incidentally) method - you gr
this
communication are not necessarily those expressed by Reed Exhibitions."
Visit our website at http://www.reedexpo.com
-Original Message-
From: Teddy Payne
To: CF-Talk
Sent: Fri Oct 06 14:29:37 2006
Subject: Re: locking, I think
scope_identity and @@identity are one type of solution. Pr
From: Aaron Rouse [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 05, 2006 4:46 PM
> > To: CF-Talk
> > Subject: Re: locking, I think
> >
> > For people who are used to SQL server, the best thing to do would be
> to
> > setup a trigger and that trigger in
all of it, and some Oracle specific features (connect
by...prior comes to mind) can be really valuable to know. The reverse,
of course, is also true.
> -Original Message-
> From: Aaron Rouse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 4:46 PM
> To: CF-Talk
>
On Friday 06 October 2006 06:23, James Holmes wrote:
> 2) Get the value from the sequence first and then do the insert,
> remembering the value that was obtained from the sequence. This can be
> done in a stored procedure or in CF code.
We did this in CF, and it worked fine.
--
Tom Chiverton
Hel
o.com
-Original Message-
From: James Holmes
To: CF-Talk
Sent: Fri Oct 06 10:34:33 2006
Subject: Re: locking, I think
Because we are using Oracle.
On 10/6/06, Robertson-Ravo, Neil (RX)
<[EMAIL PROTECTED]> wrote:
> Not sure why you would need a trigger when SCOPE_IDENTITY would
Because we are using Oracle.
On 10/6/06, Robertson-Ravo, Neil (RX)
<[EMAIL PROTECTED]> wrote:
> Not sure why you would need a trigger when SCOPE_IDENTITY would do the trick
> (or @@identity depending on your needs)
--
CFAJAX docs and other useful articles:
http://www.bifrost.com.au/blog/
~~
te at http://www.reedexpo.com
-Original Message-
From: James Holmes
To: CF-Talk
Sent: Fri Oct 06 06:23:34 2006
Subject: Re: locking, I think
Yes, but then we are back to the original question of how to get that
last ID from the DB so the code can use it.
To be completely safe, the
Yes, but then we are back to the original question of how to get that
last ID from the DB so the code can use it.
To be completely safe, there are two alternatives:
1) Use a trigger on the table to perform an "autoincrement" operation
with the sequence. Wrap the INSERT and the subsequent SELECT
M
For people who are used to SQL server, the best thing to do would be to
setup a trigger and that trigger in Oracle could grab the next sequence
value and insert it when new data is being inserted into the table.
On 10/5/06, Doug Bezona <[EMAIL PROTECTED]> wrote:
>
>
> You can access the sequence i
s trying to do.
It's just one of those quirky Oracle things. Personally, I really like
sequences, but if you're used to SQL Server, it's an odd beast.
> -Original Message-
> From: Doug Brown [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 3:46 PM
>
Here is a little snippet that may help, of course since you are using Oracle
the syntax would differ.
Using Identity Keys in SQL Server
Most applications rely on primary keys in database tables. Many of those
same applications use the auto-increment capabilities of some DBMSes like
MSSQL Server. W
In cases where I need to use the ID immediately, I use a separate query
to grab the sequence value first
Select unique_repair_ticket_s.NEXTVAL as id
>From dual
(dual, if you don't already know, being a sort of "dummy" table that you
use for this sort of thing)
Then use the result of this query f
-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 3:22 PM
To: CF-Talk
Subject: Re: Locking Theory
Mark A Kruger wrote:
>
> FIRST: User "A" does the following:
> SELECT * FROM users WHERE username = 'bob'
> WITH (updloc
Mark A Kruger wrote:
>
> FIRST: User "A" does the following:
> SELECT * FROM users WHERE username = 'bob'
> WITH (updlock)
>
> Presumably User "A" is now looking at Bob's information for editing
> on a web page
>
> SECOND: Meanwhile User "B" runs the same query
>SELE
>>It's not a database problem!
May be not, but if you don't deal with it, it WILL soon be a database
problem! ;-)
>>But your users are not connected to the database.
Right, but they are connected to a session in CF which is connected to
the database.
This is why it would be better if CF took
> Well, whether one deals with it in the SQL statement, whether one does
> it with the tools Matt Robertson designed, whether one does not deal with
> it at all. It's a question of preference. But since it's a database
> problem, and SQL is the unique way the programmer deals with the
> database,
Alrighty, thanks Jochem, i'll definitely look into those, my main
resource now is (apart from teh intarweb) books online for MS SQL
Server, but I'd like to gain a more generalized knowledge about SQL.
And and that manual, aren't you supposed to rtf it?
Mingo.
Jochem van Dieten wrote:
> And of
>>Are your users in your C program also, or are they using browsers to send
HTTP requests?
- Users use their browser to communicate with an application.
- In this application, which by the way uses sessions and session variables,
the programmer (not the user) communicates with the database thro
>>If we had to deal with the mechanics of that directly within every
SQL statement
we write, SQL would be much more difficult to write.
Well, whether one deals with it in the SQL statement, whether one does
it with the tools
Matt Robertson designed, whether one does not deal with it at all. It'
LLBACK
I'm having some trouble figuring out how this might be implemented... If
it's possible or worth it
-Original Message-----
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 9:39 AM
To: CF-Talk
Subject: Re: L
As an aside, all of what I am saying is meant to apply exclusively to
the stateless web environment. When I do client/server stuff I use
locks and handle things entirely differently, but that environment is
not stateless so I have different tools available.
--
[EMAIL PROTECTED]
Janitor, MSB Web
On 9/8/06, Claude Schneegans <[EMAIL PROTECTED]> wrote:
> >>the updlock with SQL server doesn't prevent data reads occurring when
> lock is in
> place.
>
> Sure, and no one wants to prevent reading during that time.
> BUT it will certainly prevent another updlock on the same record, thus
> prevent
> > But the environment isn't connected.
>
> It sure is: when I am in MY C program, I can create an ODBC connection
> to a datasource, and keep that connection open as long as the program
> is running. And a CFX dll can be kept running in memory as long as the
> CF server itself is running. From
Ooops forgot about that ... :)
TK
- Original Message -
From: "Claude Schneegans" <[EMAIL PROTECTED]>
To: "CF-Talk"
Sent: Friday, September 08, 2006 12:03 PM
Subject: Re: Locking Theory
> >>the updlock with SQL server doesn't prevent data r
Mingo Hagen wrote:
> That's the kind of stuff more people need to know about. Do you have any
> tips on good advanced SQL books? (Or should I have seen this in the
> basic SQL books that are out there and did I just skip this bit.)
There are few advanced SQL books that do not focus on one implem
> I don't see your point here.
> - race condition is a concurrency problem involving the database,
> - Concurrency management is handled by the database engine,
> - SQL is simply a language that can be used to interact with
> the database,
> - then, why SQL shouldn't provide tools to help the
> p
>>But the environment isn't connected.
It sure is: when I am in MY C program, I can create an ODBC connection
to a datasource,
and keep that connection open as long as the program is running.
And a CFX dll can be kept running in memory as long as the CF server
itself is running.
From that conn
>>the updlock with SQL server doesn't prevent data reads occurring when
lock is in
place.
Sure, and no one wants to prevent reading during that time.
BUT it will certainly prevent another updlock on the same record, thus
prevent someone to read it for editing also.
--
_
ng to
that solution.
TK
- Original Message -
From: "Claude Schneegans" <[EMAIL PROTECTED]>
To: "CF-Talk"
Sent: Friday, September 08, 2006 11:34 AM
Subject: Re: Locking Theory
> >>So what happens when a user has made all his or her updates just to
>
> > How on earth would such a "tool" work, in a disconnected
> > environment?
>
> By keeping the environment connected.
> A CFX is a dll written in C that can stay resident, keep ODBC
> connections opened keep user handles in memory, and handle
> time limits.
> If the CFX locks a row in the dat
>>So what happens when a user has made all his or her updates just to
be told
"We are sorry but the record you are trying to edit is locked"
Actually, this is not the way it works.
When a user reads a record for editing, the record is locked until he
updates.
During that time, when another user
Claude Schneegans wrote:
>> You had to lock a table to index it? That is soo 80'ies
>
> Yeah, after 25 years, the only difference is that the lock is handled
> automatically by the database engine.
> Not a big deal ;-)
In a current database you can continue to insert, update and delete while you
September 08, 2006 10:56 AM
Subject: Re: Locking Theory
> >>A row-level lock isn't going to come even close to that.
>
> Why not ?
> With a row locked, it is not the update by another user which will be
> refused,
> but his own "lock for editing" before he
MS SQL locking is implemented as set of hints, for example:
Ah ok, so row locks are possible with MS SQL and Oracle.
That covers most of the market.
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send
>>A row-level lock isn't going to come even close to that.
Why not ?
With a row locked, it is not the update by another user which will be
refused,
but his own "lock for editing" before he can read the record.
The system will not tell him who has locked the row, but may be it is better
like this
>>How on earth would such a "tool" work, in a disconnected environment?
By keeping the environment connected.
A CFX is a dll written in C that can stay resident, keep ODBC
connections opened
keep user handles in memory, and handle time limits.
If the CFX locks a row in the database, CF will not
Claude Schneegans wrote:
>> SELECT * FROM table WHERE id = blah FOR UPDATE
>
> Ok, but I think this syntax is proper to Oracle.
It may have originated there, but it has been in the SQL standard since at
least 1992.
> - I don't see it documented in Access, SQL Server
MS calls it WITH updlock. Y
>>SQL is simply a language that can be
used to interact with the database at a high level of abstraction.
Concurrency management is handled by the database engine, and there are many
ways this can be done. It, like database-specific physical data storage, is
below the level of SQL.
I don't see yo
: "Claude Schneegans" <[EMAIL PROTECTED]>
To: "CF-Talk"
Sent: Friday, September 08, 2006 10:20 AM
Subject: Re: Locking Theory
> >>Then I have news for you: the feature is implemented in both ODBC and
> JDBC and is standard in SQL.
>
> Ok, so it should b
>>You had to lock a table to index it? That is soo 80'ies
Yeah, after 25 years, the only difference is that the lock is handled
automatically by the database engine.
Not a big deal ;-)
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/
>>Where'd you use row level locking? A real life example?
This example has already been described in this thread:
« 1. Bob opens a web page and goes to an edit tool and selects "jenny"
to edit.
2. Sally opens a web page and goet to an edit tool and also selects
"jenny" to edit.
3. Bob updates
>>Then I have news for you: the feature is implemented in both ODBC and
JDBC and is standard in SQL.
Ok, so it should be possible to make some CFX or CFC to handle locks.
>>SELECT * FROM table WHERE id = blah FOR UPDATE
Ok, but I think this syntax is proper to Oracle.
- I don't see it documen
Hey Jochem,
That's the kind of stuff more people need to know about. Do you have any
tips on good advanced SQL books? (Or should I have seen this in the
basic SQL books that are out there and did I just skip this bit.)
Thanks,
Mingo.
Jochem van Dieten wrote:
> SELECT * FROM table WHERE id =
>>Making a web app retain some idea of a cohesive session across HTTP
requests is a
work around of the inherent statelessness of the protocol.
Ok, but workaround or not, we are able to have sessions and keep track
of them.
>>All a session
is is knowing that two distinct requests within a give
Tom Kitta wrote:
> Just remember that CF only *suggests* isolation levels and the DB actually
> does the isolation. There are four isolation levels, with most DB using read
> committed as the default level.
If the database does not support the requested isolation level it is required
to upgrade
Claude Schneegans wrote:
>
> For my applications, I have no problem presently as few people are
> working in the same time,
> but in general, how would you lock a certain record in a table while
> some one is
> working on it ?
I wouldn't. I would refuse an update to an old row version and prese
Claude Schneegans wrote:
>> For example, many databases do have the kind of locking you are talking
>> about - for example in Oracle you can do select...for update, which
>> locks the selected record until the update is completed by the session
>> that initiated the select.
Actually, until the tra
Claude Schneegans wrote:
> This what so simple in 1980's, with dBase, clipper, Foxpro you name it,
> under DOS.
> All had Rlock() and Flock() functions.
> Rlock() was used when editing a record, Flock() locked the whole file,
> for instance
> while indexing a table.
You had to lock a table to in
How about solving it with AJAX or using Flash forms that use sockets to
check whatever the current user is still editing? You could even popup a
message like "You are taking a long time to edit" or "Someone else wants to
edit this data - please either release it or finish your work ASAP".
TK
> Please, I'm not that dumb, I know what an application is compared to a
> simple web page.
Never suggested you were dumb, just pointing out the root of the issue.
> All the same, we coldFusion developpers, are able to create complete
> multi-user
> true applications and work around THE HTTP "sta
Well, here's my results, which show that serializable is NOT the
default isolation level, at least for Oracle (10G), in CFMX6.1.
I ran two templates.
TEMPLATE 1
SELECT PKID,SOMEDATA
FROM TESTTRANSACTION
Before UPDATES:
PK: #PKID# DATA:
#QGetSomeData.SomeData#
UPDATE T
> If you have time, do the same and we can compare notes.
Unfortunately, I don't have CF where I am right now. Nor do I have a
database. In fact, I barely have a computer. But a better approach for
testing might be to create an SQL trace; I'm pretty sure that'll show you
your isolation level direc
I think the needs of a grownup application are well beyond simply
row-locking a table. You don't want the db to refuse an update. You
want the user to attempt to visit a record and be told "Bubba is using
this record already. You can look at it but if you want to do more
click here to yell at Bu
It's easy enough to test, which I'll do in a moment.
1) Write a page containing a transaction without an explicit level.
Between two queries in that transaction (maybe an update and a
select), make CF sleep for 10 seconds. Run the page
2) Run a second page that also does an update query, in the sl
> The default still depends on the DB and how it is set up.
>
> "If you do not specify a value for the isolation attribute,
> ColdFusion uses the default isolation level for the
> associated database."
>
> http://livedocs.macromedia.com/coldfusion/7/htmldocs/0346.htm
>
> For Oracle this is
The default still depends on the DB and how it is set up.
"If you do not specify a value for the isolation attribute, ColdFusion
uses the default isolation level for the associated database."
http://livedocs.macromedia.com/coldfusion/7/htmldocs/0346.htm
For Oracle this is often Read Committe
> Just remember that CF only *suggests* isolation levels and
> the DB actually does the isolation. There are four isolation
> levels, with most DB using read committed as the default level.
I don't think this is correct. When you specify an isolation level, that's
what the database uses. And, if
> Just what I thought, there is not tool available for this,
> neither in CF, nor ODBC, nor SQL. This is just unbelievable,
> now in 2006 with the database systems we have!
> This what so simple in 1980's, with dBase, clipper, Foxpro
> you name it, under DOS.
> All had Rlock() and Flock() functi
> > What are you saying here? That there is no way
> > (ncorrectly) to row lock in SQL?
>
> Not in the SQL standard as far as I know.
> Do you have an example ?
Locking, or more broadly, how concurrency is managed, is not described in
SQL. It has nothing to do with SQL - SQL is simply a language
> > ... in general, how would you lock a certain
> > record in a table while some one is working on it ?
>
> Cftransaction with the isolation attribute. Check the docs
> for the various options.
That's not going to get you very far. It will prevent two concurrent
requests from simultaneously man
On 9/7/06, Claude Schneegans <[EMAIL PROTECTED]> wrote:
> >>it's easier to treat every update as an insert, and just keep a
> history of who's done what when, and what was there before.
>
> Easier? This is just a patch to eventually fix problems by hand when
> they appear,
> PROVIDED someone finds
>>It is up to the vendor to supply locking, it will never be in a standard
Ok, it's up to vendors to supplies things to compensate for lacks in the
standard,
not the contrary.
I mean if vendors develop new options, it is because they are somehow
necessary,
then it's a reason good enough why it
On 9/7/06, Robertson-Ravo, Neil wrote:
> What are you saying here? That there is no way (ncorrectly) to row lock in
> SQL?
If he is I'd agree with him, insofar as the web/intranet environment
is concerned.
I wrote LockMonger to manage the locking of records at the application
level. Doesn't do d
-
From: Claude Schneegans
To: CF-Talk
Sent: Thu Sep 07 23:00:30 2006
Subject: Re: Locking Theory
>>What are you saying here? That there is no way (ncorrectly) to row
lock in
SQL?
Not in the SQL standard as far as I know.
Do you have an example ?
--
__
xhibitions."
Visit our website at http://www.reedexpo.com
-Original Message-
From: Claude Schneegans
To: CF-Talk
Sent: Thu Sep 07 23:00:30 2006
Subject: Re: Locking Theory
>>What are you saying here? That there is no way (ncorrectly) to row
lock in
SQL?
Not in the SQL standard
>>What are you saying here? That there is no way (ncorrectly) to row
lock in
SQL?
Not in the SQL standard as far as I know.
Do you have an example ?
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send
--Original Message-
From: Claude Schneegans
To: CF-Talk
Sent: Thu Sep 07 22:20:38 2006
Subject: Re: Locking Theory
>>The problem it seems is that you are expecting a web app to behave like
a classic client server app. Unfortunately, HTTP is a stateless
protocol, and simply doesn't behave
>>The problem it seems is that you are expecting a web app to behave like
a classic client server app. Unfortunately, HTTP is a stateless
protocol, and simply doesn't behave the same way.
Please, I'm not that dumb, I know what an application is compared to a
simple web page.
All the same, we col
g statelessness of HTTP.
> -Original Message-
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 07, 2006 3:29 PM
> To: CF-Talk
> Subject: Re: Locking Theory
>
> >>it's easier to treat every update as an insert, and just keep a
&g
>>it's easier to treat every update as an insert, and just keep a
history of who's done what when, and what was there before.
Easier? This is just a patch to eventually fix problems by hand when
they appear,
PROVIDED someone finds it, not really a method to PREVENT problems from
happening.
>>D
On 9/7/06, Claude Schneegans <[EMAIL PROTECTED]> wrote:
> >>cftransaction could lock for the duration of user edit ... it however,
> depending on the DB level of locking could prevent any other user from
> reading data in the table. I would consider implementing such locking a bug
> not a feature.
>>cftransaction could lock for the duration of user edit ... it however,
depending on the DB level of locking could prevent any other user from
reading data in the table. I would consider implementing such locking a bug
not a feature.
Of course, db level locking is abusive.
One should be able to
ROTECTED]>
To: "CF-Talk"
Sent: Thursday, September 07, 2006 10:13 AM
Subject: Re: Locking Theory
> Select with no lock should allow results to be returned - though it will
> effectively be a dirty read.
>
>
>
>
>
>
>
> "This e-mail is from Reed
edexpo.com
-Original Message-
From: Tom Kitta
To: CF-Talk
Sent: Thu Sep 07 17:03:20 2006
Subject: Re: Locking Theory
cftransaction could lock for the duration of user edit ... it however,
depending on the DB level of locking could prevent any other user from
reading data in the tabl
cftransaction could lock for the duration of user edit ... it however,
depending on the DB level of locking could prevent any other user from
reading data in the table. I would consider implementing such locking a bug
not a feature.
Try the following in SQL server query analyzer: Begin Tran [so
>>I assume that users want to look at the record, make changes and save
without having to worry about any other user doing the same thing to the
same record at the same time.
Depends what you call "user", I would rather say "developer" here.
For me, the user is the one who uses the applications I
1 - 100 of 361 matches
Mail list logo
