Locking In CFML

cavalcadejewelΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

82 εμφανίσεις

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

Multithreading

The 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

Multithreading

Advantages

-

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

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/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 Locks


Avoid 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 Locks

Name idetifies the lock and denies access to

protected ressource for all locks with the same

name

Use it for all critical ressources except shared

scope variables, e.g..



Verity



<CFFILE>



COM
-
Objects

Recommended: use a naming convention!

Locking in CFML

Lock
-
Administration

Single Threaded Sessions

All 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 Settings


No 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 Settings


Full 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 Settings


Automatic 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 l
ocal
out approach


Locking in CFML

Questions?

Christoph Schmitz

eMail: info@procept.net



Presentation for Download available at

http://www.procept.net