[CF] Table locking ?

[Defspace]

Ik zit met het volgende probleem.
Ik gebruik onderstaande code om een document in te voeren in de database(Access)

code:

<cftransaction action="begin">
<cfset commitIt="Yes">
<cftry>

<CFQUERY datasource="datasource" name="qry_name_1">
    insert into Documents select * from TempDocs where ID=#ID#
</CFQUERY>
<CFQUERY datasource="datasource" name="qry_name_2">
    delete from TempDocs where ID=#ID#
</CFQUERY>

<cfif commitIt EQ "Yes">
<cftransaction action="COMMIT" />
</CFIF>
<cfcatch type="Database">
    Er is een fout opgetreden. ;)
    <cfset commitIt = "No">
    <cftransaction action="ROLLBACK" />
    <cfabort>
</cfcatch>
</cftry>
</cftransaction>

Maar nu zit ik er mee dat ik wanneer ik tegelijkertijd deze actie (met verschillende document ID's) in werking zet op 2 verschillende pc's (i-net is toch multiuser ) De ene goed gaat (die net iets eerder was) en de ander de melding: "Er is een fout opgetreden. ;)" krijgt.
Het lijkt mij dus dat hij een table lock toepast bij de verwerking van deze transaction.
Ik heb alle combinaties van isolation al geprobeerd, maar iedere keer hetzelfde effect. Ik zou graag willen dat hij alleen een row-lock toepast ???

In de manual staat het volgende

Within a transaction block, you can write queries to more than one database,but you
must commit or rollback a transaction to one database before writing a query to another.
Using CFML error handling, you control whether each transaction is committed, based
on the success or failure of the database query. To control how the database engine
performs locking during the transaction, use the isolation attribute.

Hij rollt de transactie wel op de goede manier terug.
Maar het moet toch wel multiuser kunnen ?? Daarom bouw ik juist transacties in, om te zorgen dat er geen fouten optreden door multi-user actievitieten.

Heeft iemand hier ervaring mee ?

[Juup]

Kun je niet checken of hij gelockt/bezig is, 1 sec wachten en dan nog een keer proberen? (Hammer hammer)

[Roeligan]

<cftransaction action="begin">
<cfset commitIt="Yes">
<cftry>
<CFQUERY datasource="datasource" name="qry_name_1">
insert into Documents select * from TempDocs where ID=#ID#
</CFQUERY>
<CFQUERY datasource="datasource" name="qry_name_2">
delete from TempDocs where ID=#ID#
</CFQUERY>

<cfif commitIt EQ "Yes">
<cftransaction action="COMMIT" />
</CFIF>
<cfcatch type="Database">
Er is een fout opgetreden.
<cfset commitIt = "No">
<cftransaction action="ROLLBACK" />
</cfcatch>
</cftry>
</cftransaction>

zo zou die moeten zijn

[Defspace]

Op dinsdag 23 juli 2002 14:05 schreef Roeligan het volgende:

zo zou die moeten zijn

Sorry ?
Das toch hetzelfde?

En Jaaap, volgens mij heb ik geen functies om te checken of de table gelocked is ? En ook geen functies om een paar sec te wachten (behalve tot 100000000 tellen ofzo

[jochemd]

Op dinsdag 23 juli 2002 14:21 schreef Defspace het volgende:

En Jaaap, volgens mij heb ik geen functies om te checken of de table gelocked is ?

Dat zou ik niet weten. Een van de redenen waarom ik liever geen Access gebruik maar een database die daar geen problemen mee heeft.

En ook geen functies om een paar sec te wachten (behalve tot 100000000 tellen ofzo

Even zelf schrijven. Wordt zoiets als:

code:

<cfset waitTime = 5>
<cflock name="wait" type="readonly" timeout="10">
    <cflock name="wait" type="exclusive" timeout="#waitTime#" throwonerror="No">
    </cflock>
</cflock>

[mulder]

Waar slaat die trouwens die commitIt op?

[Defspace]

Op dinsdag 23 juli 2002 14:47 schreef Don Facundo het volgende:
Waar slaat die trouwens die commitIt op?

Zodra er een error is, wordt commitIT op No gezet, en zal de transactie dus niet meer ge"commit" worden.

Jochemd, jij denkt dat dit echt te maken heeft met Access en dat mijn code,cq opties correct zijn ?
Als ik dit dus zou uitvoeren tegen een Postgresql database, dan moet dit goed gaan denk jij ?

[Roeligan]

hij is idd bijna hetzelfde... volgens mij moet die abort eruit...

[Defspace]

hij is idd bijna hetzelfde... volgens mij moet die abort eruit...

Nee die abort heb ik er zelf in gezet. Zonder abort doet ie het ook goed (vanwege "CommitIT") Maar ik wil juist dat ie abort als die foutmelding komt.
Dit is ook eigenlijk alleen maar een stukje sample code. In mijn echte page zit wat meer functionaliteit, en wat meer queries, maar het gaat om het idee. Hierop loopt ie dus ook al stuk met 2 request op het zelfde moment.

[jochemd]

Op dinsdag 23 juli 2002 15:28 schreef Defspace het volgende:

Jochemd, jij denkt dat dit echt te maken heeft met Access en dat mijn code,cq opties correct zijn ?
Als ik dit dus zou uitvoeren tegen een Postgresql database, dan moet dit goed gaan denk jij ?

Met PostgreSQL is het zelfs iets simpeler, daar hoef je meestal niet aan expliciete rollbacks te doen. Elke foutmelding van de database zorgt op zichzelf al voor een rollback. Onderstaande code (copy-paste van iets dat ik heb liggen) is dus al ACID compliant, zonder er iets van een rollback in voorkomt.

code:

<cftransaction action="BEGIN">
<cfquery datasource="#request.dsn#" username="#request.dsn_user#" password="#request.dsn_pass#">
    UPDATE current
    SET
        babyxl   = (SELECT colo FROM status WHERE telco = 1 and status.cgbnr = current.cgbnr),
        bbned    = (SELECT colo FROM status WHERE telco = 2 and status.cgbnr = current.cgbnr),
        bbned_ls = (SELECT ASL FROM status WHERE telco = 2 and status.cgbnr = current.cgbnr),
        mxstream = (SELECT colo FROM status WHERE telco = 3 and status.cgbnr = current.cgbnr)
</cfquery>
<cfquery datasource="#request.dsn#" username="#request.dsn_user#" password="#request.dsn_pass#">
    INSERT INTO metingen (datum, naam, babyxl, bbned, bbned_ls, mxstream, versatel)
    VALUES (
        current_timestamp, 
        'current', 
        (SELECT count(*) FROM status WHERE telco = 1 and colo = TRUE),
        (SELECT count(*) FROM status WHERE telco = 2 and colo = TRUE),
        (SELECT count(*) FROM status WHERE telco = 2 and ASL = TRUE),
        (SELECT count(*) FROM status WHERE telco = 3 and colo = TRUE),
        (SELECT count(*) FROM status WHERE telco = 4 and colo = TRUE)
        )
</cfquery>

<cftransaction action="commit"/>
</cftransaction>

Hoewel ik bovenstaande slechts tweewekelijks als batch draai, zie ik geen reden om te veronderstellen dat het niet concurrent kan draaien. PostgreSQL gebruikt MVCC, dus in principe is er van locking helemaal geen sprake meer (in het scenario zoals ik dat tot dusverre heb gezien).

[mulder]

transaction<>locking volgens mij. En aan Access zal het echt niet liggen, dit is een prima database, onderschat door sommigen. Dan zal toch eerder liggen aan hoe ColdFusion met Access (en andere db's) omgaat.

Ik heb nog effe naar die vreemde commitIt gekeken, die hebje dus uit het voorbeeldje uit de help. In jou code heeft ie weinig zin zo te zien...

[jochemd]

Op dinsdag 23 juli 2002 16:33 schreef Don Facundo het volgende:
transaction<>locking volgens mij.

Klopt. In dit geval is waarschijnlijk de locking het probleem, waardoor een bepaalde query niet lukt, en kan je misschien transacties gebruiken om te zorgen dat je database consistent blijft.

En aan Access zal het echt niet liggen, dit is een prima database, onderschat door sommigen. Dan zal toch eerder liggen aan hoe ColdFusion met Access (en andere db's) omgaat.

ColdFusion praat ODBC. Als het in andere databases wel kan en in Access niet, dan denk ik eigenlijk wel dat het aan Access ligt. Om preciezer te zijn, aan de ODBC driver of aan de manier waarop Access is ingesteld. Je kan namelijk in Access instellen of er op row-level gelocked moet worden of op table-level. Welke is het momenteel?
Een ander puntje is dat je CF kan limiteren op een bepaald aantal connecties naar een datasource. Als dat er momenteel 1 is zal je ook een probleem krijgen.

Maar volgens mij hebben we het hier al eerder gehad over het opschalen van deze applicatie en is het niet geheel toevallig dat hier PostgreSQL als voorbeeld werd genoemd

[Defspace]

Op dinsdag 23 juli 2002 16:33 schreef Don Facundo het volgende:
Ik heb nog effe naar die vreemde commitIt gekeken, die hebje dus uit het voorbeeldje uit de help. In jou code heeft ie weinig zin zo te zien...

Zo vreemd is die niet hoor in het voorbeeld heeft hij geen zin idd, maar die cfabort blijft er niet staan...

ColdFusion praat ODBC. Als het in andere databases wel kan en in Access niet, dan denk ik eigenlijk wel dat het aan Access ligt. Om preciezer te zijn, aan de ODBC driver of aan de manier waarop Access is ingesteld. Je kan namelijk in Access instellen of er op row-level gelocked moet worden of op table-level. Welke is het momenteel?
Een ander puntje is dat je CF kan limiteren op een bepaald aantal connecties naar een datasource. Als dat er momenteel 1 is zal je ook een probleem krijgen

CF is goed ingesteld. (Limit connections staat uit, preserve connection aan, daarbij is het natuurlijk altijd alleen maar de webserver(odbc) die een connectie heeft met die db.)
Wanneer ik op hetzelfde moment iets toevoeg in dezelfde database, maar een andere tabel, is er geen probleem. Het heeft dus echt met een tabel lock te maken.
In Access staat "Default Record locking" op "No Locks" en "open databases using record-level locking" aan. Zijn er nog meer opties?

[mulder]

Misschien [url="http://www.vboston.com/DepressedPress/Content/ColdFusion/Guides/Locking/3-LockingToTheRescue.cfm"]een stukje proza[/url].

[Defspace]

Op dinsdag 23 juli 2002 18:11 schreef Don Facundo het volgende:
Misschien [url="http://www.vboston.com/DepressedPress/Content/ColdFusion/Guides/Locking/3-LockingToTheRescue.cfm"]een stukje proza[/url].

Dank je. Dat zou het best wel eens kunnen zijn dan.
Maar ik kan het nu niet meer testen. Ik zit nu thuis, en mijn server is te snel om dit te testen en heb hier geen beschikking over 2 clients. (op werk heeeeel trage ontwikkelbak. Wel goed om te testen, ontgaat niks je )
Ik begrijp dus hieruit dat ik mijn hele transaction binnen een lock moet zetten, en dan zorgt CF ervoor dat die mooi in de wachtrij wordt geplaatst en op zijn beurt mag wachten. Dat zou mooi zijn.
Morgen weet ik weer meer.

[Defspace]

Het probleem doet zich idd niet meer voor nadat ik een kleine CFlock implementatie heb gedaan.

Maar na het lezen van dat verhaaltje ben ik wel gaan twijfelen over mijn applicatie.
Wanneer moet ik _echt_ cflock gebruiken ?
Is het altijd slim om een <cfapplication> tag in application.cfm te zetten ?
Waarom sluit je een <cfapplication> tag niet af ?
Komt dat omdat ie gewoon de session laat time-outen ?
Ik maak zo ver ik weet geen gebruik van shared scope variables, alleen van shared data access, moet ik dan gewoon alle writes e.d. tussen locks zetten ?

TIA