[CF] Variabele variabele namen

[Verwijderd]

Ik ben nog niet zo lang met Coldfusion aan het werken.
Nu wil ik werken met variabele variabele namen.
Ik zal maar vlug even de code erbij zetten, anders is het moeilijk om het uit te leggen.

code:

<cfloop index="organizercount" from="1" to="#session.numberOrg#">
  <cfoutput><select name="organizer_#organizercount#"></cfoutput>
    <cfoutput query="een_query_in_oracle_db">
      <option value="#organizer_id#">#organizer_name#</option>
    </cfoutput>
  </select>
</cfloop>

Dit werkt zonder enig probleem.
Nu moet in de select de optie geslecteerd worden waarvoor een andere variabele "session.organizer_#organizercount#" gelijk is aan de organizer_id uit de database.
Ik heb dat geprobeerd op verschillende manieren, maar in een CF-tag kan hij blijkbaar niet overweg met dit soort variabele variabele-naam.

code:

bij de option tag invoegen:
<cfif 'session.organizer_'#organizercount# eq #organizer_id#> selected </cfif>
of
<cfif 'session.organizer_'&#organizercount# eq #organizer_id#> selected </cfif>

werkt dus niet.

Is er iemand die weet hoe ik dit probleem zou kunnen oplossen?
Eventueel met één of andere omweg?
(ik heb me al rot gezocht op Google en op verschillende Coldfusion sites, en ik heb ook al 2 boeken geraadpleegd, maar ik vind dus geen oplossing)

[ Voor 10% gewijzigd door Verwijderd op 26-04-2004 16:49 . Reden: typo ]

[Verwijderd]

Ik ken geen ColdFusion, maar bij de meeste problemen waarbij je "variabele variabelen" hoort, zijn arrays de oplossing.

[jochemd]

code:

<cfif session["organizer_#organizercount#"] eq organizer_id> selected </cfif>

[Verwijderd]

Een kleine tip, let er op dat je session variables locked. Locking voorkomt dat threads geshuffeld worden tussen meerdere tokens.

Vanuit Macromedia is er geen eenduidige richtlijn voor locking, de één zegt, altijd locken, de ander zegt alleen indien nodig. En dat indien nodig duidt op code die het risico loopt intensief aangeroepen te worden.

Mijn persoonlijk idee hierop, is om uit beveiligsredenen en stabiliteit altijd te locken. In CF 5 heb je nog de mogelijkheid om dit te ontlopen dmv de optie single thread locks in de CF Administrator, maar dat levert een performance hit op.

Ook locken resulteerd in een performance hit, maar een server die plat ligt (de meeste instabiliteit in CF server ligt nog steeds bij locking problemen in de applicaties die erop draaien) heeft een grotere performance hit.

[Alarmnummer]

Ik ben altijd huiverig als ik iets zie over threads en ben altijd blij als ik ze via kant en klare systemen (EJB bv) of patterns niet meer zelf hoef op te lossen. Iedereen kan locken, maar hoe gaan jullie om met deadlocks? Zit er een timeout op een bepaalde actie en worden alle locks dan ook weer netjes vrij gegeven?

[Verwijderd]

Alarmnummer schreef op 26 april 2004 @ 21:32:
Ik ben altijd huiverig als ik iets zie over threads en ben altijd blij als ik ze via kant en klare systemen (EJB bv) of patterns niet meer zelf hoef op te lossen. Iedereen kan locken, maar hoe gaan jullie om met deadlocks? Zit er een timeout op een bepaalde actie en worden alle locks dan ook weer netjes vrij gegeven?

Ja, je kunt zelf een timeout instellen Uit performance oogpunt is er geen interne harde controle op threads, en die kun je dus forcen vanuit de server, of via code

Op zich levert het niet al teveel problemen op, totdat je merkt dat bepaalde gegevens behorende bij een sessie worden verwisseld met een andere sessie. En daarvoor is dus locking, om zulke zaken te voorkomen.

Of het verstandig zou zijn geweest om dat native in te bouwen, tja, ik denk het wel.

Sinds CFMX draait CFMX op een J2EE laag, daarvoor nog op C++ code, maar ik heb eigenlijk sinds de J2EE overstap geen actieve vraagstukken meer gezien rond locking.

[ Voor 9% gewijzigd door Verwijderd op 26-04-2004 21:50 ]

[Verwijderd]

Ik heb zojuist even gesproken met Ben Forta, een evangelist van Macromedia op CF gebied, en hij gaat er een post aan wijden op zijn eigen blog. http://www.forta.com/blog/

edit:

De posting is zojuist geplaatst, en voor de geinteresseerden staat hier het hele verhaal uitgelegd.

http://www.forta.com/blog/index.cfm?mode=e&entry=1139

Conclusie: alleen locken om race conditions te voorkomen.

[ Voor 44% gewijzigd door Verwijderd op 26-04-2004 22:30 ]

[Verwijderd]

In ieder geval allemaal zeer vriendelijk bedankt.
Het is me op deze manier gelukt! Ook bedankt voor de tip ivm locken. Ik heb het draadje op het andere forum ook gelezen, maar eerlijk gezegd ben ik er nu nog steeds niet helemaal uit.
De toepassing die ik nu aan het schrijven ben is er ééntje die op een goede dag ongeveer 5000 read requests te verwerken krijgt. Het schrijven gebeurt een heel stuk minder frequent. Ongeveer 14 schrijf opdrachten per week worden er nu genoteerd. Maar om 1 volledig nieuwe instantie in te geven in de database wordt er naar een 30-tal tabellen geschreven en de totale tijdsduur die hiervoor nodig is bedraagt ongeveer 2 uur (nu in zuiver statische HTML zijn 2 mensen hier full-time mee bezig). Het is dus wel mogelijk dat er gelijktijdige writes plaatsvinden.
De coldfusion server die we hier gebruiken is nog de 4.5 versie.
Uit hetgeen ik hier gelezen heb leid ik af dat wanneer ik niets ga locken, ik dus bijna onvermijdelijk om problemen ga vragen. (en dan te zeggen dat ik nog nooit van locken gehoord had)
Maar heeft dit locken in mijn geval zin? We gebruiken geen server en applicatie variabelen, enkel een paar sessie-variabelen (voor de login en voor het bijhouden van alle gegevens die naar de database moeten geschreven worden tot het moment dat we ze ook effectief gaan schrijven.)
In hoeverre heeft dit locken in dit geval dan zin?
(ik hoop dat mijn vraag ongeveer duidelijk gesteld is)

[Verwijderd]

Aangezien je 4.5 gebruikt zou ik altijd gaan locken. 4.5 heeft nogal wat instabiliteitsproblemen bij het niet locken Application, Server, en Session variables hebben locking nodig, een Client variable neit.

Het hangt natuurlijk ook af wat je gaat doen 5000 reads is echt peanuts

[ Voor 42% gewijzigd door Verwijderd op 27-04-2004 11:53 ]