locking in cfml

Post on 19-Jan-2016

43 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Locking In CFML. Locking in CFML. }. Understand Locking. - Why. - What. to lock?. - How. - When. Locking in CFML. The problem – symptoms and reasons. Agenda. Critical ressources. Shared Scope Variables. . Nested locks. Locks and pointers. Name Locks. - PowerPoint PPT Presentation

TRANSCRIPT

Locking In CFML

Locking in CFML

- Why

- How

- What

- When}to lock?

Understand Locking

Locking in CFML

Agenda The problem – symptoms and reasons

Critical ressources

Shared Scope Variables

<CFLOCK>

Nested locks

Locks and pointers

Name Locks

Lock Administration

Locking in CFML

Symptome für ein Locking-Problem

- unerklärliche Verluste von Session- oder Application-Variablen

- Serverabstürze

- speichergierige CF-Server

- langsame Anwendungen

Locking in CFML

MultithreadingThe ability of a program to perform multiple tasks at the same time.

Exanple: eMail client

Read messages and download new messages from the server at the same time

Locking in CFML

MultithreadingAdvantages- performance / saves time

- (system-) security

Drawbacks- Programs are more complicated

- not easy to implement

Locking in CFML

Multithreading in ColdFusion

ColdFusion can handle multiple requests at the same time

Every request is assigned to a thread

Additional requests will be queued

Within a Thread the request is serialized

Number of Worker Threads can be set in CF-Administrator

Locking in CFML

Critical Ressources

Shared Scope Variables

Files

Component objects (COM, CORBA, Java)

All ressources that could cause problems or loose performance if there are multiple clients accessing them

Concurre

nt Acc

ess

Locking in CFML

Shared Scope Variables

Server-Scope

Application-Scope

Session-Scope

Accessible by EVERY client of EVERY application on that server

Accessible by EVERY client of ONE SINGLE application

Accessible by ONE SINGLE client of ONE SINGLE application

frames, multiple submits, reload/redirectionframes, multiple submits, reload/redirection

Locking in CFML

<CFLOCK>

Identification

Type

Error Handling

NAME or SCOPE

TYPE=“Exclusive”vs.

TYPE=“ReadOnly”

TIMEOUT and THROWONTIMEOUT

Category Attributes

Locking in CFML

<CFLOCK> and Shared Scope Variables

Lock EVERY SINGLE access

Lock the entire scope

use the correct locking type

lock only what needs to be locked

Locking in CFML

Example: store query recordset in application variable

Wrong:<CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFQUERY datasource="#DSN#" name="application.customers"> SELECT * FROM tblCustomers </CFQUERY></CFLOCK>

Better:<CFQUERY datasource="#DSN#" name=“customers"> SELECT * FROM tblCustomers</CFQUERY><CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFSET application.customers = customers></CFLOCK>

Locking in CFML

Nested Locks Deadlocks possible

<CFLOCK scope="Application" Timeout="10" type="ReadOnly"> <CFLOCK scope="Application" Timeout="10" type="Exclusive"> Code... </CFLOCK></CFLOCK>

Template 1:<CFLOCK scope="Application" Timeout="10" type="Exclusive">

<CFLOCK scope="Session" Timeout="10" type="Exclusive">Code...

</CFLOCK></CFLOCK>

Template 2:<CFLOCK scope="Session" Timeout="10" type="Exclusive"> <CFLOCK scope="Application" Timeout="10" type="Exclusive"> Code... </CFLOCK></CFLOCK>

Locking in CFML

Nested Locks<CFLOCK scope="Application" Timeout="10" type="Exclusive">

<CFLOCK scope="Session" Timeout="10" type="Exclusive"> <CFSET session.DSN = application.DSN> <CFSET application.bgcolor = session.bgcolor>

</CFLOCK></CFLOCK>

<CFLOCK scope="Application" Timeout="10" type="ReadOnly"> <CFSET dsn = application.DSN></CFLOCK> <CFLOCK scope="Session" Timeout="10" type="ReadOnly"> <CFSET bgcolor = session.bgcolor></CFLOCK> <CFLOCK scope="Application" Timeout="10" type="Exclusive">     <CFSET application.bgcolor = bgcolor></CFLOCK> <CFLOCK scope="Session" Timeout="10" type="Exclusive"> <CFSET session.DSN = DSN></CFLOCK>

Locking in CFML

Nested LocksAvoid nested locks if at all possible

(performance issues, danger of deadlocks)

1. session scope

If you can’z avoid nesting, always lock in the following order:

2. application scope

3. server scope

“Local out” approach

Locking in CFML

Locking of Pointers

Pointer: points to a structure (is NOT a real copy!)

<CFSET application.userData = session>

Changing the pointer also changes initial structure

<CFSET myPointer = myStruct>

Shared scope variablen are structures!

<CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFSET application.userData = session> </CFLOCK>

<CFLOCK scope="Session" Timeout="10" type="ReadOnly"> <CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFSET application.userData = session> </CFLOCK> </CFLOCK>

<CFLOCK scope="Application" Timeout="10" type="ReadOnly"> <CFSET temp = application.userData.bgcolor> </CFLOCK> <CFSET temp = application.userData.bgcolor>

<CFLOCK scope="Session" Timeout="10" type="ReadOnly"> <CFLOCK scope="Application" Timeout="10" type="ReadOnly"> <CFSET temp = application.userData.bgcolor> </CFLOCK> </CFLOCK>

<CFSET application.userData.bgcolor = "##EEEEEE"> <CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFSET application.userData.bgcolor = "##EEEEEE"> </CFLOCK>

<CFLOCK scope="Session" Timeout="10" type="Exclusive"> <CFLOCK scope="Application" Timeout="10" type="Exclusive"> <CFSET application.userData.bgcolor = "##EEEEEE"> </CFLOCK> </CFLOCK>

Locking in CFML

Name LocksName idetifies the lock and denies access toprotected ressource for all locks with the

samenameUse it for all critical ressources except sharedscope variables, e.g..

Verity

<CFFILE>

COM-Objects

Recommended: use a naming convention!

Locking in CFML

Lock-Administration

Single Threaded SessionsAll thread with the same sessionID are serialized

concurrent access with session variables impossible

performance drawbacks (e.g. with frames) template timeouts more likely to

occur

Locking in CFML

Lock-Administration

Variable Scope Lock Settings

No automatic checking or locking

Full checking

Automatic read locking

Locking in CFML

Lock-Administration

Variable Scope Lock SettingsNo automatic checking or locking

developer is responsible for proper locking

good performance but dangerous

Use this setting for production servers with TESTED applications

Locking in CFML

Lock-Administration

Variable Scope Lock SettingsFull checking

every unlocked access throws an exception

secure, but small performance drawbacks

use it for development servers

for shared Servern

Name Locks also throw exceptions

Locking in CFML

Lock-Administration

Variable Scope Lock SettingsAutomatic read locking

every read access is automatically locked

quite secure, but has serious performance drawbacks useful if you need to add locks to an older applications

write acesses must be locked manually

Locking in CFML

Summary

1. Lock EVERY access

2. If possible sum up accesses in a single lock, but,

3. Lock only what needs to be locked

4. For Shared Scope Variables always use the SCOPE attribute

5. Use the correct locking type

6. Avoid server scope on shared servers

Locking in CFML

Summary (continued)

8. THROWONERROR=“Yes” ist useful, but, you need to catch exceptions with CFTRY/CFCATCH

9. Avoid pointers between different scopes vermeiden. Better use StructCopy() oder Duplicate().

10. If pointer can not be avoided: lock both scopes.

11. For production servers use “No automatic checking or

locking” setting (with TESTED applications only!)12. For development server use “Full checking” setting

7. Avoid nested locks; if you need to nest locks, use local out approach

Locking in CFML

Questions?

Christoph SchmitzeMail: info@procept.net

Presentation for Download available athttp://www.procept.net

top related