> > > Ooops I meant "suggest locking" not "suggest isolation
> > > levels". You can of course set isolation levels in CF and
> > > this is the way CF recommends locking type to the DB.
> >
> > Again, though, I don't think this is a recommendation - I'm
> > pretty sure that whatever you choose for your isolation level
> > will tell the database exactly how to impose and honor locks.
>
> Well, this isn't strictly true either.  Some databases can
> escalate locks above what you've specified - this is usually
> a good thing though.

Yes, I've oversimplified things a bit; I apologize. I stand by my statement
that the isolation level isn't a recommendation, which is what I was getting
at. In no case will the database ever say, "well, you don't need this
transaction to be serializable, so I won't bother setting any locks". The
database may well escalate the scope of a lock, locking a page or a table
instead of two or more individual records, and it may place a stronger lock
as a result of that. As far as I can tell, within your transaction all you
can really specify are whether locks will be placed and whether they'll be
honored, and whether those locks will apply to the records being touched or
to the dataset which describes those records. Those specifications will be
honored. (I'll note that I probably oversimplified a sentence or two here,
as well.)

But in any case, this kind of argument emphasizes the importance of
understanding how your database works when you want to write transactional
processing code. This isn't trivial or necessarily obvious stuff, but too
few CF developers understand it sufficiently, I think. For that matter, I'm
not sure I understand it sufficiently!

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to