11
1.4 Concurrency
Concurrencycontrolisanissueforallofthesystemsdiscussedabove,andsomeofthe
basicapproacheshavealreadybeenmentioned.Thistopichasalonghistory,withmany
proposedmethodsofdealingwithproblemsofpreventingdatainconsistencyinthepresence
ofmultipleindependentprocessesmodifyingthesamedata.Themostmajordistinctionin
traditionalconcurrencycontrolisthatbetweenoptimisticandpessimisticmethods.Pessimis-
ticalgorithmsuselocksorproactivelyabortupdateoperationsthatmightleadtoinconsis-
tencyinadatastructure.Thisalwaysguaranteesthatthedataisconsistent,butdoesnot
guaranteethatallupdatescanbeperformedataparticulartime.Theguaranteeofconsis-
tencyisenforcedbyensuringthatthehistoryofoperationsisserializable:thatthefinal
stateofthedatastructureisthesameaswouldresultfromsomeserialexecutionoftheac-
ceptedoperations.Inthegeneralcase,apessimisticalgorithmmayblockoneupdateen-
tirelyinfavorofanother,thusabortinganupdatethatwouldconflictwithanotherupdate.
Optimisticalgorithmsallowupdatestoproceed,determiningaslateaspossiblewhethera
serializabilityconflicthasoccurred.Onecommonthreadleadingthroughallthetraditional
methodsofconcurrencycontrolisthatdataisalwaysmaintainedinaconsistentstate.This
reflectstheACIDpropertiesrequiredofdatabasesystems:transactionsshouldbeAtomic,
Consistent,IsolatedandDurable.
However,collaborationsupporthasratherdifferentrequirementsthanadatabaseback-
end.Formanyphasesoftheauthoringprocess,theAtomicityofcomplexchanges,andrigid
enforcementofConsistencyconstraintsinintermediateandworkingversionsarelowerpri-
oritytasks.Whilethefinalproductsofcollaborativeeffortsmayhavequiterigidrequire-
ments,theauthoringprocessisnotpermanentlydamagedbysloppydrafting,intheway
thatadatabasecanbecomecorruptedbytheconsequencesofevenasmallinconsistency.
Durabilityofresultsisimportantinbothcases.Systemstosupportauthorsanddesigners
12
canalsogainrealvaluebyprovidingdurableeditinghistories,somethingthatmanydata-
basescanlivewithout.Authoringhistoriesalsomustbeabletorepresentandhandlecon-
flictingandbranchinglinesofdevelopment,sincetheyareinherenttotheauthoringproc-
ess,whiletheanalogoussituationsindatabasesareruledoutaprioribytheconsistency
requirements.Isolationisaconceptthatreallyonlyappliesinthecontextofatransaction
basedsystem.Infact,wewillseethatforcollaborationwewanttoincreasetheabilityto
mergechangesproductively,somethingthatwillactuallyincreasethepotentialforinterac-
tionsbetweenchanges.
Theforgoingpointsaremoregenerallytrueincollaborativesystems,wheremoreliberal
optimisticmethodsaresometimesusedtocompensateorproceed,eveninthepresenceof
non-serializable(conflicted)executionhistories.Thisispossiblebecauseofthepresenceof
thehumanauthors,acriticalfactorinvolvedincollaborationthatisnotavailableintypical
databasesystems.Beyondautomaticpolicies,thereisalwaysalastresortincollaboration:a
humanbeingthatcanbetrustedtocorrectlyresolveaconflict(ifsheiswillingandauthor-
izedtodoso).Furthermore,formostapplications,theneedforabsoluteconsistencyiscon-
siderablyless.Dourish(Dourish1996)hasproposedtwolevelsofconsistencyforcollabora-
tionsupportsystems:syntacticconsistencyandapplicationconsistency.Syntactic
consistencyisconsistencyinthedatastructuresthatsupporttheimplementationofapplica-
tions;iftheseareinconsistent,thereisabuginthesystemandthesoftwarewillfailto
workcorrectlyoratall.Applicationinconsistencyisdifferent.Itreferstotheconsistencyof
thedatamodelimpliedbyanapplication,whetherthatisamodelforatext,astructured
drawing,orsomeotherapplicationobject.Aninfrastructurethatcansupportdivergence
fromacompletelyconsistentdatamodelisessentiallyanoptimisticconcurrencycontrol
model,wherehumancollaboratorsareresponsibleforresolvingconflicts.Theadvantageof
suchdatamodelsisthesameasthatforoptimisticconcurrencycontrol:greateravailability
toupdates,atthecostofgreatertimeexpendedresolvingconflicts.
Previous Page Next Page