[ALG] Meerdere users in cms

[gvdh81]

Ongetwijfeld hebben jullie dit wel eens meegemaakt, je bent bezig met een beheersysteem (maakt in princiepe niet uit in welke taal) en je komt erachter dat er meerdere users tegelijkertijd aan 1 record (of 1 file) aan het werken zijn en dat natuurlijk tegelijkertijd.

Nu was mijn vraag (aangezien mijn inleiding nogal moeilijk google't ), hoe dit het beste opgelost kan worden. Zelf zat ik te denken om dit bij te houden in een tabel, met de volgende (pseudo) opzet:

code:

tabelnaam
recordid
companyid
userid
locktime

Als je het zou willen uitbreiden met ook het werken met bestanden zou je ipv tabelnaam en recordid ook een lockid kunnen construeren voor een item.

Alles spreekt voor zich behalve de locktime. Dit is een timestamp (bijv een *nix timestamp) die de tijd van locken opslaat. Deze lock zal verwijderd worden zodra de gebruiker het item opslaat of naar een andere pagina navigeert. Aangezien je ook rekening moet houden met het feit dat gebruikers de browser kunnen sluiten en mijn gebruikers automatisch uitloggen na 1 uur, kun je dus ook automatisch de records ouder dan 1 uur verwijderen zodat een item maximaal 1 uur gelocked blijft.

Tot zover mijn huidige gedachtengang en ideeen hierover; Heeft iemand hier ideeen over, of zijn er toevallig ergens artikelen verschenen waarin dit soort constructies naar voren komen? Ik kan natuurlijk ook in de source van bijv. Mambo CMS gaan kijken maar ik probeer eerst zelf iets te verzinnen wat werkt (voor de uitdaging )

[whoami]

Je hebt 2 soorten locking, optimistic locking, en pessismtic locking.

Bij de eerste soort ga je er van uit, dat het praktisch nooit voorkomt dat 2 users tegelijkertijd aan dezelfde data prutsen.
Is dit wel het geval, dan verliest één van de 2 users z'n werk. Optimistic locking kan je implementeren door op iedere tabel bv een timestamp column toe te voegen. Die timestamp wordt iedere keer aangepast bij een update.
Zo kan je er dus voor zorgen dat een update enkel kan slagen, als de timestamp nog steeds dezelfde waarde heeft, als de waarde voor dat de gebruiker met zijn wijziging begon.

Bij pessimistic locking, ga je ervoor zorgen dat, als één gebruiker een bepaald record geopend heeft, een andere gebruiker dat record niet kan wijzigen, tot wanneer die andere gebruiker dat andere record weer 'vrijgegeven' heeft. Dat heeft dan wel als voordeel dat niemand z'n werk verliest, maar als nadeel dat je soms lang moet wachten vooraleer je jouw werk kunt doen.

Aan jou om een optie te kiezen.

[Verwijderd]

Je hebt diverse soorten locking, waarvan de optimistic lock in de meeste gevallen wordt gebruikt in een web omgeving. De optimistic lock betekend dat er aan het begin van het wijzigen een "capture" wordt gemaakt van de data, en op het moment van saven controleerd of de huidige data nog steeds overeenkomt met die "capture". Zoniet pech, dan kan je niet saven want iemand anders heeft dan al gesaved.

Het nadeel is dus, dat de persoon die dus later saved, niet meer kan saven omdat een eerdere persoon wijzigingen heeft aangebracht. Je zou dit eventueel ook kunnen afhandelen door alleen een waarschuwing te geven als "Een andere gebruiker heeft dit record aangepast".

Dan heb je ook nog de pessimistic lock, en die is op het web lastig toe te passen. Het houdt in dat je echt een object "vastzet" op een user. Elke andere persoon krijgt vanaf dat moment geen toegang meer tot het object, totdat hij weer wordt vrijgegeven. Het vrijgeven is echter lastig, want of je gaat het automatisch doen bij een window.onunload of je gaat het handmatig doen. Op het moment echter, dat de browser crashed, of er iets anders gebeurt dan wordt die lock niet vrijgegeven en moet er dus interventie plaatsvinden.

Er zijn nog andere locks, maar dit zijn de meest gebruikelijke.

[ Voor 14% gewijzigd door Verwijderd op 10-06-2005 12:03 ]

[gvdh81]

Momenteel gebruik ik dus nog geen locking omdat het (nog) niet voorkomt dat er meerdere gebruikers in hetzelfde systeem werken. Optimistic locking kan ik dus wel toepassen en ik denk dat met mijn inleiding ook pessimistic locking is te realizeren, maar ik moet dan wel goed nadenken waar ik de locks zet en waar ik de locks weer vrijgeef. Met deze informatie kan ik in ieder geval wel verderkomen. Toch zou ik het fijn vinden als dit topic nog even opengehouden kan worden om meerdere ideeen te spuien

edit:
Ik zie alleen wel een probleem bij optimistic locking..
Als ik dus zo werk dat ik een revision tag meegeef, de gebruiker bijv. 1 uur aan het werk is in dat record en vervolgens zijn wijzigingen niet op kan slaan (omdat iemand anders hem voor was en de tag dus is gewijzigd) krijg ik dus een boze gebruiker aan de lijn...

Dit is toch een reeele mogelijkheid?

Leuk leesvoer (nu ik op de juiste termen zoek)
- http://www.issociate.de/b...istic_Record_Locking.html
- http://getluky.net/?p=45
- http://lists.evolt.org/ar...-Mon-20040517/159315.html

[ Voor 42% gewijzigd door gvdh81 op 10-06-2005 12:23 . Reden: urls toegevoegd ]

[TheekAzzaBreek]

Ik neem aan dat je op een database werkt.
Als je applicatie verschil maakt tussen bekijken en bewerken, je hebt b.v. een edit knop, kan je toch gewoon een expliciete lock zetten als iemand wil gaan bewerken? In veel DB's verdwijnt de lock vanzelf bij een commit. En als de gebruiker gewoon z'n applicatie sluit /PC crasht of wat dan ook, zal een beetje DB dat zien en de sessie + lock opruimen.

[Verwijderd]

TheekAzzaBreek schreef op vrijdag 10 juni 2005 @ 12:27:
Ik neem aan dat je op een database werkt.
Als je applicatie verschil maakt tussen bekijken en bewerken, je hebt b.v. een edit knop, kan je toch gewoon een expliciete lock zetten als iemand wil gaan bewerken? In veel DB's verdwijnt de lock vanzelf bij een commit. En als de gebruiker gewoon z'n applicatie sluit /PC crasht of wat dan ook, zal een beetje DB dat zien en de sessie + lock opruimen.

En hoe lang duurt die sessie dan? Als iemand bij een record moet dat 20 minuten vaststaat heb je een probleem

[Verwijderd]

whoami schreef op vrijdag 10 juni 2005 @ 11:57:
[...]
Is dit wel het geval, dan verliest één van de 2 users z'n werk.
[...]

Dat is niet helemaal waar, ligt er maar aan hoe je het bouwt. Verschil optimistic/pessimistic locking zit hem in het moment van signaleren van conflicten: bij pessimistic is dit voordat je het item wilt openen, bij optimistic pas als je het item wilt opslaan.

Of iemand zijn werk verliest is helemaal afhankelijk van hoe je het conflict oplost: als je eenmaal detecteert dat een item gewijzigd is kun je ook een heel merge scenario gaan uitvoeren. Dat kan heel ingewikkeld zijn (zoals bij code control systemen als CVS en Subversion) maar kan ook heel eenvoudig door een linkje te plaatsen naar een pagina met de huidige versie en de gebruiker te vragen of hij zijn wijzigingen toch wil opslaan. Eventueel kan de gebruiker dan handmatig mergen.

[Verwijderd]

In principe komt dit probleem toch niet eens voor bij een CMS. Ik neem aan dat diegene die verantwoordelijk zijn voor bepaalde data weten wie op welk moment wijzigingen doorvoert.

Verder kun je gewoon data naar je database schrijven want als het goed is hebje zo gemodelleerd dat je niet muteert maar enkel toevoegt.

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 13:12:
In principe komt dit probleem toch niet eens voor bij een CMS.

Bij de 90% aan gebruik van hakkietakkie CMS systemen niet. Echter bij multi user omgevingen waar CMS een need to have is komt dit wel degelijk voor. Het komt zelfs voor dat meerdere personen aan eenzelfde object werken, en waar je dus op property locked.

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 13:20:
Bij de 90% aan gebruik van hakkietakkie CMS systemen niet. Echter bij multi user omgevingen waar CMS een need to have is komt dit wel degelijk voor. Het komt zelfs voor dat meerdere personen aan eenzelfde object werken, en waar je dus op property locked.

Noem eens een real-life voorbeeld dan. Ik kan me juist voorstellen dat het bij de hakkie-takkie cms-en eerder voorkomt aangezien die ontwikkelt worden voor minder professionele bedrijven.

[ Voor 1% gewijzigd door Verwijderd op 10-06-2005 13:58 . Reden: door moest voor zijn, 1 letter -> wereld van verschil ]

[gvdh81]

Bij de weg; in mijn voorbeeld ga ik er vanuit dat een user een record edit (dus opent, gegevens uit database ophalen met mogelijkheid om te saven). Ik kan het ook zo maken dat wanneer een record al ge-edit wordt, er alleen een view van het record mogelijk is, met een melding ozid.

En ik denk overigens NIET dat je wilt gaan locken op DB niveau in een web cms. Ik bedoel, je zult meer controle hebben over wie wat aan het doen is als je lockt op applicatieniveau.

[TheekAzzaBreek]

Verwijderd schreef op vrijdag 10 juni 2005 @ 12:50:
[...]

En hoe lang duurt die sessie dan? Als iemand bij een record moet dat 20 minuten vaststaat heb je een probleem

Een probleem, of een feature. Een groot cms systeem als Interwoven werkt ook met expliciete locks, zonder timeouts. Kan je een lock dagen laten staan, en nog vrij veel klanten willen dat ook zo. Het is maar hoe je de verantwoordelijkheden voor een stukje content hebt georganiseerd, en content is opgedeeld.

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 13:26:
Noem eens een real-life voorbeeld dan. Ik kan me juist voorstellen dat het bij de hakkie-takkie cms-en eerder voorkomt aangezien die ontwikkelt worden voor minder professionele bedrijven.

Jazeker, en binnen dat soort bedrijven wordt zeer weinig gewerkt in een multi user situatie. Die systemen zijn dus ook pertinent een gevaar voor grotere omgevingen waar men bijvoorbeeld in een redactie samenwerkt.

[TheekAzzaBreek]

Verwijderd schreef op vrijdag 10 juni 2005 @ 13:26:
[...]
Noem eens een real-life voorbeeld dan. Ik kan me juist voorstellen dat het bij de hakkie-takkie cms-en eerder voorkomt aangezien die ontwikkelt worden voor minder professionele bedrijven.

Voorbeelden? De bewerkers zitten op ander plek / ander timezone dan de verantwoordelijken, b.v. Of een deel van de content komt van een helmaal externe partij, die bv nieuwsberichtjes aanlevert. Of verantwoordelijke is afwezig, maar werk gaat wel door in afwachting van zijn goedkeuring.

Je kan je beter afvragen waarom je sowieso een cms wil hebben als je dit soort dingen niet hoeft te regelen.

[Arjan A]

Je kan ook XMLHTTPRequest gebruiken om de locking actief te houden.
Bijv een javascriptje dat controleert of er de laatste x minuten uberhaupt nog getypt is op die pagina (mocht de pagina open blijven staan) en het item automatisch unlockt na een waarschuwing oid waarop niet wordt gereageerd.

[Verwijderd]

TheekAzzaBreek schreef op vrijdag 10 juni 2005 @ 14:31:
Een probleem, of een feature. Een groot cms systeem als Interwoven werkt ook met expliciete locks, zonder timeouts. Kan je een lock dagen laten staan, en nog vrij veel klanten willen dat ook zo. Het is maar hoe je de verantwoordelijkheden voor een stukje content hebt georganiseerd, en content is opgedeeld.

Ware het niet dat Interwoven volgens een "take ownership" situatie werkt, en niet automatisch een lock toekent aan een object. Dat omdat het systeem van nature is ontwikkeld uit een document management oplossing. De gebruiker zal zelf een checkout moeten doen, en dan krijg je de pessimistic lock. Ik ben zelf niet een voorstander van het checkout/checkin principe.

Het werken met een systeem is voor veel gebruikers al moeilijk genoeg, en een gebruiker heeft ook wel wat anders te doen dan zich druk maken om concurrency problemen die een systeem voor hem zou kunnen afhandelen. Dan kan de gebruiker zijn aandacht richten op content en alles wat direct bij die content behoort, en zich niet druk maken om de technische details ter preventie van data corruptie. Checkin/checkout regel je imo via workflow (bijvoorbeeld na een final version), en locking automatisch bij het starten en eindigen van een bewerking

[TheekAzzaBreek]

Verwijderd schreef op vrijdag 10 juni 2005 @ 14:40:
[...]


Ware het niet dat Interwoven volgens een "take ownership" situatie werkt, en niet automatisch een lock toekent aan een object. Dat omdat het systeem van nature is ontwikkeld uit een document management oplossing. De gebruiker zal zelf een checkout moeten doen, en dan krijg je de pessimistic lock. Ik ben zelf niet een voorstander van het checkout/checkin principe.

Dat is niet juist. Het locking model is instelbaar, maar de meest toegepaste methode is automatisch locken, dus lock op het moment dat je opent voor bewerking (niet eens als je start met bewerken!), en unlock bij submit.

Het werken met een systeem is voor veel gebruikers al moeilijk genoeg, en een gebruiker heeft ook wel wat anders te doen dan zich druk maken om concurrency problemen die een systeem voor hem zou kunnen afhandelen. Dan kan de gebruiker zijn aandacht richten op content en alles wat direct bij die content behoort, en zich niet druk maken om de technische details ter preventie van data corruptie. Checkin/checkout regel je imo via workflow (bijvoorbeeld na een final version), en locking automatisch bij het starten en eindigen van een bewerking

Ik ben het wel met je eens, maar het een kwestie van filosofie, en een beetje van organisatie. Er zijn meerder bruikbare aanpakken te verzinnen.

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 14:33:
Jazeker, en binnen dat soort bedrijven wordt zeer weinig gewerkt in een multi user situatie. Die systemen zijn dus ook pertinent een gevaar voor grotere omgevingen waar men bijvoorbeeld in een redactie samenwerkt.

Binnen een groter bedrijf is er altijd een iemand verantwoordelijk voor de data van een bepaald onderdeel. Er zal dus eigelijk altijd maar 1 iemand gelijktijdig hetzelfde onderdeel wijzigen. Sowieso werk je dan met voorstellen van een wijzinging die worden doorgestuurd naar een eindverantwoordelijke voor rectificatie. Zodoende hoef je nooit te locken aangezien je de wijziging onder 1 eindverantwoordelijke onderbrengt.

Bottomline, locken binnen een CMS is slecht ontwerp (workflow) en redundant.

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 14:53:
Bottomline, locken binnen een CMS is slecht ontwerp (workflow) en redundant.

No offence, maar zonder met dikke piemels te smijten is dit echt niet de bottomline in organisaties waar men veel met content bezig is. Er is namelijk een zeker bedrijf in Amsterdam wat een enkel object door meerdere personen laat bewerken, en waar het dus gebeurt dat 2 mensen tegelijkertijd bezig zijn met een enkel artikel. Als er geen locking zou worden toegepast zou dit niet mogelijk zijn. Met je stelling zeg je ook in principe dat al die andere CM systemen die locking hebben geimplementeerd gewoon een brak ontwerp hebben.

[ Voor 11% gewijzigd door Verwijderd op 10-06-2005 15:01 ]

[Verwijderd]

Je kan een object wel door meerdere personen laten bewerken, maar het gaat om de workflow. Dus de business dient beter beschreven te worden. Als je dat doet kom je erachter dat "locken" niet nodig is. Je hoeft enkel te "assignen".

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 15:13:
Je kan een object wel door meerdere personen laten bewerken, maar het gaat om de workflow. Dus de business dient beter beschreven te worden. Als je dat doet kom je erachter dat "locken" niet nodig is. Je hoeft enkel te "assignen".

Jij bedoelt een systeem wat via taken werkt, en niet direct vanuit een repository. Maar dan nog, hoe ga je om met een workflow die parallel loopt? Je ontkomt niet aan locking, ook niet via workflow rules tenzij je in functionaliteit gaat inkrimpen.

Dus met een parallel workflow, een zegge artikel wat vanuit de auteur wordt verzonden naar de juridische afdeling voor controle, en waar de mogelijkheid bestaat dat in de gehele juridische groep approval plaats gaat vinden. Op het moment dat Mr. Kees het artikel wil gaan reviewen mag het dus nooit zijn dat Mr. Henk hetzelfde gaat doen (tenzij je voor optimistic kiest, maar dan heb je een readonly lock).

Het locking model is instelbaar

Net even gechecked, je hebt gelijk

[ Voor 35% gewijzigd door Verwijderd op 10-06-2005 15:20 ]

[djluc]

Verwijderd schreef op vrijdag 10 juni 2005 @ 15:13:
Je kan een object wel door meerdere personen laten bewerken, maar het gaat om de workflow. Dus de business dient beter beschreven te worden. Als je dat doet kom je erachter dat "locken" niet nodig is. Je hoeft enkel te "assignen".

En nu even zonder vage termen: wat bedoel je dan precies met assignen?

[Verwijderd]

Nee hoor. Zoals ik al zei is er maar 1 iemand verantwoordelijk voor de uiteindelijke inhoud. Dus alle paralelle taken (wat dus opzich al slecht is want dat is dubbel werk en zal een bedrijf dus niet graag willen) zijn enkel voorstellen en niet directe wijzigingen.

djluc schreef op vrijdag 10 juni 2005 @ 15:17:
[...]
En nu even zonder vage termen: wat bedoel je dan precies met assignen?

Toekennen

Of was dat te makkelijk?

Een wijziging moet worden toegekent aan een persoon die daadwerkelijk de wijziging maakt.

[ Voor 38% gewijzigd door Verwijderd op 10-06-2005 15:21 ]

[Verwijderd]

Verwijderd schreef op vrijdag 10 juni 2005 @ 15:19:
zijn enkel voorstellen en niet directe wijzigingen.

Wat bedoel je hier mee? Als Kees en Harry in dezelfde groep zitten, en die groep krijgt het artikel voor review dan krijgen Kees en Harry allebei de awaiting review lijst te zien. Dan heb je al locking nodig. Dat is het hele principe van parallel workflow, een van de personen uit de groep kan approval geven, en wie precies dat maakt niet uit anders had ik hem wel direct in een serial workflow geplaatst.

[gvdh81]

juist en wat gordijnstok aandraagt wil ik graag gaan maken;
- Automatisch "checkout" (lees: lock) bij het openen van het record en verwijderen van lock bij het opslaan / wegnavigeren van het record.
- Tevens is er een sessie timeout van een uur, dus een record zal automatisch worden vrijgegeven door het systeem na een uur. Hij moet namelijk toch een page refresh doen ozid voordat hij door kan werken.

Wat inderdaad kan is een xmlHTTPRequest inbouwen wat de sessie "actief" houd en dus ook de lock actief houd.

[Soultaker]

Volgens mij is pessimistisch locken echt vragen om problemen in een 'onbetrouwbare' omgeving als het web. Ik heb het idee dat je het alternatief nogal snel hebt afgeschreven omdat een aantal mensen aankwamen met "bij een conflict verliest één van de twee gebruikers zijn werk". Dat is wel de meest slechte manier om een conflict op te lossen zoals paullooijmans eerder al opmerkte.

Een uitgebreidere vergelijking van de twee mogelijkheden wordt ook beschreven in het Subversion boek, onder Versioning Models. De conclusie:

The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is far less than the time lost by a locking system.

In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false promise that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else.

De complexiteit beperkt zich tot de methode om conflicten op te lossen (waar al standaardtools als patch en diff voor zijn) zonder dat je je druk hoeft te maken om het vrijgeven van locks (wat heel onbetrouwbaar werkt in een webbased omgeving).

Sowieso is het een goed uitgangspunt om er voor te zorgen dat locks maar heel kort vastgehouden worden; een systeem waarbij je op de menselijke gebruiker moet zitten wachten terwijl die een verhaal typt voldoet daar absoluut niet aan.

[ Voor 14% gewijzigd door Soultaker op 10-06-2005 16:43 ]

[Verwijderd]

Soultaker schreef op vrijdag 10 juni 2005 @ 16:42:
Volgens mij is pessimistisch locken echt vragen om problemen in een 'onbetrouwbare' omgeving als het web.

Er zijn redelijk wat valkuilen, absoluut. Maar er zijn genoeg mogelijkheden om pessimistic locking toe te passen, maar dat vereist wel dat men de techniek beheerst. Men neigt nogal snel te zeggen "kan niet" omdat ze niet snappen dat web specialistenwerk is. Zelfde voor het web als "onbetrouwbaar" bestempelen terwijl er redelijk wat grote jongens zijn die het tegendeel laten zien (Microsoft CRM bijvoorbeeld) Je kunt een combinatie creeren van unload, extra controleren op interval maar dan ga je de /13 kant op

In een windows client zal je ook iets met timeouts moeten doen, bijvoorbeeld om een programma crash op te vangen.

[ Voor 12% gewijzigd door Verwijderd op 10-06-2005 16:55 ]

[Soultaker]

Dat er tientallen niet-portable hacks bestaan om de onvolkomenheden weg te poetsen betekent niet dat het handige oplossingen zijn. Integendeel, het onderschrijft alleen maar de onbetrouwbare aard van het web.

IP adressen zijn niet vast. Sessies worden niet betrouwbaar afgesloten, want unload handlers werken niet altijd. Je kunt op geen enkele betrouwbare manier zien of een sessie afgelopen is.

Verwijderd schreef op vrijdag 10 juni 2005 @ 16:54:
In een windows client zal je ook iets met timeouts moeten doen, bijvoorbeeld om een programma crash op te vangen.

Dat klopt, maar er is een enkele betrouwbare en portable manier om te detecteren dat een TCP-verbinding verbroken is, terwijl dat voor websessies absoluut niet geldt.

Maar belangrijker nog dan de technische problemen is dat gebruikers onbetrouwbaar zijn. Wat als ik een pagina open, een stuk type, en dan ga lunchen? Het is nogal wrang als ik dan mijn wijzigingen kwijt ben door een time-out van een lock. Omgekeerd is het ook nogal vervelend als ik de pagina open en niemand kan er vervolgens meer bij, terwijl ik ben gaan lunchen. Exclusieve locks en langdurige 'transacties' zijn gewoon een slecht idee, dat zullen juist mensen uit de concurrency/database hoek kunnen bevestigen, niet webontwikkelaars.

[ Voor 19% gewijzigd door Soultaker op 10-06-2005 17:22 ]

[Verwijderd]

Goed, de meningen verschillen daarover. Jij praat over hacks, terwijl het gewoon functionaliteit is om iets te bereiken. Checks op TCP/IP verkeer, het is leuk maar moet het realtime zijn?

Wat als ik een pagina open, een stuk type, en dan ga lunchen? Het is nogal wrang als ik dan mijn wijzigingen kwijt ben door een time-out van een lock. Omgekeerd is het ook nogal vervelend als ik de pagina open en niemand kan er vervolgens meer bij, terwijl ik ben gaan lunchen. Exclusieve locks en langdurige 'transacties' zijn gewoon een slecht idee, dat zullen juist mensen uit de concurrency/database hoek kunnen bevestigen, niet webontwikkelaars.

Je hoeft je wijzigingen helemaal niet kwijt te zijn door een time-out. Dat een sessie op het web een timeout krijgt, ben ik absoluut met je eens, maar hier zijn zoveel mogelijkheden voor om dit op te vangen, oa door temporary saves, die een MS Word standaard ook doet. Dat je in een windows applicatie dat niet hoeft te doen, absoluut eens, maar het Web is gewoon een kwestie van zaken anders aanpakken, en wellicht met extra functionaliteit.

Dat web ontwikkelaars geen verstand hebben van concurrency issues is een vooroordeel wat je van nature software ontwikkelaars vaak ziet roepen, maar wat mijnziens ook echt bij een vooroordeel blijft. Ik merk dat er vooral bij software ontwikkelaars weinig interesse is om zich echt te verdiepen in de mogelijkheden die er tegenwoordig zijn voor het web, de vooroordelen die ik meestal hoor komen vaak voor uit angst, onwetendheid en desinteresse (nofi overigens ). Het grootste deel van de opmerkingen en vooroordelen zijn ook binnen notime weerlegt door web ontwikkelaars, maar een verhaaltje doet snel zijn ronde en zo ontstaat een afkeer.

Web doet het gewoon goed. Er zijn zeker wat nadelen, ontken ik niet; generic drag n drop, systeemtoegang, maar real world applicaties hebben binnen zeer korte tijd bewezen dat er eigenlijk maar bizar weinig drempels zijn voor de average applicatie. De verkoopcijfers van ondemand van Siebel schieten de lucht in (primair ontwikkeld omdat Salesforce toch wel erg snel marktaandeel inpikte), Microsoft CRM hakt erin, en Microsofts Webmail toont het access anywhere principe van web applicaties goed aan.

[ Voor 5% gewijzigd door Verwijderd op 10-06-2005 18:55 ]

[Kayshin]

Op school (HSZuyd Heerlen TIS) krijgen we in onze projecten ook te maken met multi-user systemen. Onze oplossing is hier door een timestamp mee te geven aan het record, deze ook aan de user mee te geven en bij het opslaan te kijken of deze overeenkomen. Zo niet, dan is het record al geupdate in de tussentijd en kan je bijvoorbeeld inbouwen dat de user dan het geupdate record krijgt te zien, waarna hij dan kan kiezen om toch op te slaan of om het bewerkte record te behouden.

[gvdh81]

Je kunt op geen enkele betrouwbare manier zien of een sessie afgelopen is.

Hier ben ik het niet mee eens, ik gebruik namelijk PHP en ADODB en log mijn sessies in een tabel. Er is een session_notifier die aangeeft welke sessies zullen verlopen (en dus ook die data nogmaals kunt ophalen). Zodoende krijg je geen problemen met "lost locks" en kun je locks netjes afsluiten.

Op zich vind ik het idee wel gaaf wat je aanbrengt (het copy-modify-merge model);
Kijk welke velden de user heeft gewijzigd, en alleen als die velden van het record al eerder zijn gewijzigd (sinds dat hij het record opende voor editen) heb je een probleem. Ik zal eens gaan kijken of dit te doen is, dan hoef ik geen locking toe te passen maar kan ik alsnog aangeven "Let op, een andere gebruiker is momenteel dit record aan het wijzigen".

[Verwijderd]

Ik heb in dit topic al 2* XMLHttpRequest zien voorbij komen maar er wordt bizar weinig aandacht aan geschonken. Ook voor mij is dit hele 'ding' (object) nieuw, ben nooit een fan geweest van Javascript (clientside scripting) i.c.m. serverside sripting maar dit bied denk ik echt een erg eenvoudige oplossing voor iets dat toch wel complex is. Je kunt hier met Javascript een soort van keep-alive laten sturen naar de server waardoor deze weet dat dit record/object niet door anderen bewerkt mag worden, komt dit verzoek niet binnen geef dan het object weer vrij voor andere gebruikers. Het lijkt misschien te simpel maar kan toch goed werken in een multi-user omgeving.

[Soultaker]

gvdh81 schreef op maandag 13 juni 2005 @ 18:42:
Hier ben ik het niet mee eens, ik gebruik namelijk PHP en ADODB en log mijn sessies in een tabel. Er is een session_notifier die aangeeft welke sessies zullen verlopen (en dus ook die data nogmaals kunt ophalen). Zodoende krijg je geen problemen met "lost locks" en kun je locks netjes afsluiten.

Het probleem blijft dat je afhankelijk bent van een time-out, die redelijk lang moet duren, als je er een hele webpagina in vol wil kunnen typen. Even snel een pagina bijwerken aan het einde van de dag is er niet meer bij als die pagina per ongelijk gelockt is, want je moet dan toch echt die time-out afwachten, tenzij je dus clientside technieken gebruikt om je op de hoogte te stellen dat een lock vrijgegeven kan worden, maar die zijn weer relatief onbetrouwbaar en slecht portable en bovendien maakt dat de implementatie (en bijbehorende documentatie en testen) een stuk uitgebreider en complexer.

Maar goed, voor beide methoden valt wel wat te zeggen; pessimistisch locken is aantrekkelijker naarmate collisions frequenter zijn en/of de tijdsduur van een lock kleiner is; pessimistisch locken werkt goed met client-side functionaliteit terwijl optimistisch locken geheel server-side te implementeren is (wat fijn is als je alleen nauwkeurige controle hebt over de servers, zoals op het web). Wat in jouw situatie het beste werkt kun je zelf waarschijnlijk het beste beslissen en als jij na beide opties te hebben bekeken tot de conclusie komt dat pessimistisch locken je beter uitkomt dan zal je daar vast gelijk in hebben.

[gvdh81]

Momenteel is het CMS wat ik heb ontwikkeld nog xhtml 1.0 strict icm php en smarty, maar ik zit er zwaar over na te denken om er een RIA (Rich internet application) van te maken want dat ziet er toch net wat gelikter uit en is denk ik (op 2 kleine punten) zeer haalbaar. De twee punten zijn dan een WYSIWYG editor en file uploads, maar dat kan natuurlijk altijd nog via een popup of zoiets dergelijks. Het is trouwens niet echt een CMS te noemen, je beheert er wel content mee, maar vooral tabellen (zoals agenda, nieuws, mailinglist etc)

@drunk; Zoals Soultaker al aangaf is er nog een derde optie; "copy-modify-merge model"; misschien dat ik daar eens naar ga kijken. Dat XMLHttpRequest werkt wel heel goed maar het vergt wel een aantal aanpassingen die denk ik niet nodig zijn met de derde methode.

@soultaker; Mijn cms heeft momenteel een timeout van 60 minuten. Op 45 minuten krijgen ze de eerste waarschuwing (via javascript textbox) en op 55 minuten de tweede en laatste. Dit idee heb ik geleend van horde, die ook zoiets doet.

[ Voor 14% gewijzigd door gvdh81 op 14-06-2005 23:46 ]