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 when in
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
--
cfset session.foo = application.bar
It depends.
What version of CF is this?
Is there
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:
cflock scope=session type=EXCLUSIVE timeout=10
cfset session.foo = application.bar
/cflock
(timeout can be whatever is appropriate)
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
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
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
@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?
@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
On Mon, Jun 1, 2009 at 16:59, Jay Greer m...@gobluerocket.com 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,
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.
@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
@ 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 almost
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 slaba...@po-box.esu.edu wrote:
I am using the Alagad Captcha Component and am not familiar with CFLOCK.
Is
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:
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 needed
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
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
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 think James
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
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
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:
alright, I'm gonna try
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 Software
://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, there are two
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/
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 do the
trick
(or @@identity depending
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
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
Subject: Re: locking, I think
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
Subject: Re
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. Primary Keys
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 grab
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
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 for
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.
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
To: CF-Talk
Subject: Re: locking, I think
Here is a little snippet
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 in a
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
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
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
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 index
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
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 present
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
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 given
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 =
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 documented
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 jenny
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
: Claude Schneegans [EMAIL PROTECTED]
To: CF-Talk cf-talk@houseoffusion.com
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 be possible to make some CFX
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
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. You
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 be
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
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
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 can read the record.
The system will not tell him who has locked
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
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
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
to
that solution.
TK
- Original Message -
From: Claude Schneegans [EMAIL PROTECTED]
To: CF-Talk cf-talk@houseoffusion.com
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
be told
We are sorry
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.
--
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
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
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
Ooops forgot about that ... :)
TK
- Original Message -
From: Claude Schneegans [EMAIL PROTECTED]
To: CF-Talk cf-talk@houseoffusion.com
Sent: Friday, September 08, 2006 12:03 PM
Subject: Re: Locking Theory
the updlock with SQL server doesn't prevent data reads occurring when
lock
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
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 someone
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
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: Locking Theory
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's
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
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
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, I
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
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
SELECT * FROM users
-
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 (updlock)
Presumably User A is now
. The opinions expressed within this
communication are not necessarily those expressed by Reed Exhibitions.
Visit our website at http://www.reedexpo.com
-Original Message-
From: Jenny Gavin-Wear
To: CF-Talk
Sent: Thu Sep 07 07:43:30 2006
Subject: RE: Locking Theory
Hi Ben,
Could you explain
Thanks Neil
-Original Message-
From: Robertson-Ravo, Neil (RX)
[mailto:[EMAIL PROTECTED]
Sent: 07 September 2006 07:53
To: CF-Talk
Subject: Re: Locking Theory
A race condition is a condition is where a value may be not what you expect
when you get/set it. This is normally the case
http://en.wikipedia.org/wiki/Race_condition
http://searchstorage.techtarget.com/sDefinition/0,,sid5_gci871100,00.html
http://www.tech-faq.com/race-condition.shtml
Mark
On 9/7/06, Jenny Gavin-Wear [EMAIL PROTECTED] wrote:
Hi Ben,
Could you explain the term race condition please?
Jenny
--
Ok, the definitions says :
A race condition occurs when multiple processes access and manipulate
the same data concurrently
I remember, when I was working on applications in Clipper ages ago, we
had to lock records or files
in the database, and those locks were managed by DOS, not by the
Cflock, ensures that this never happens, as Ben will only ever be able to
chance value a to Ben after you have finished with it.
Yes, but what is locked is the template in which one can modify ANY
record in
the database, not just Jenny, so no one should be able to modify
anything during the
Cftransaction with the isolation attribute. Check the docs for the
various options.
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 10:19 AM
To: CF-Talk
Subject: Re: Locking Theory
Ok, the definitions says :
A race condition
I was pointing out locking of variables in scope rather than DB locking.
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: 07 September 2006 15:23
To: CF-Talk
Subject: Re: Locking Theory
Cflock, ensures that this never happens, as Ben will only ever be able
--
YOU Wrote:
but in general, how would you lock a certain record in a table while some
one is working on it ?
This is a bit different from the discussion so far - which has concentrated
on locking as it pertains to avoiding errors and race conditions. You can
lock a
Cftransaction with the isolation attribute.
Ok, but the lock terminates with the closing /CFTRANSACTION tag, right ?
So how could one
1. lock a record,
2. read the record
3. edit the record
4. update the record
5. unlock the record ?
At least (1,2,3) and (4,5) could be in different templates.
: Thursday, September 07, 2006 10:23 AM
Subject: RE: Locking Theory
Cftransaction with the isolation attribute. Check the docs for the
various options.
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 10:19 AM
To: CF-Talk
are talking ms here not even seconds.
TK
- Original Message -
From: Claude Schneegans [EMAIL PROTECTED]
To: CF-Talk cf-talk@houseoffusion.com
Sent: Thursday, September 07, 2006 10:48 AM
Subject: Re: Locking Theory
Cftransaction with the isolation attribute.
Ok, but the lock terminates
But perhaps you are asking how to allow someone to edit data without
being overwritten by someone editing the same data.
Well, this is exactly what one would call a race condition, isn't it ?
Sally's update has overwritten Bobs
Exact, this is actually what should be avoided in any database
I was pointing out locking of variables in scope rather than DB locking.
Exact, but locking variables is just a way of doing some db locking,
otherwise, it is not very useful. The real thing is db locking.
And what if you have two different applications using the same database?
--
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
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
-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 table. I would consider
-Talk cf-talk@houseoffusion.com
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 Exhibitions (Oriel House, 26 The Quadrant,
Richmond
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
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.
[...]
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.
DB's
-
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
history of who's done what when, and what was there before.
Easier? This is just
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
-
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 same way.
Please
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
.
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 as far as I know.
Do you
: 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 ?
--
___
REUSE CODE! Use
1 - 100 of 348 matches
Mail list logo
