Changes between Initial Version and Version 6 of Ticket #301

Show
Ignore:
Timestamp:
01/17/10 00:59:55 (16 years ago)
Author:
boomfish
Comment:

The issue still exists in Model-Glue 3, but the code in question has been completely rewritten so none of the patches provided will work.

Suggested fix is to inject the ModelGlue_APP_KEY string into the SessionBasedStatePersister bean and have the bean prefix the _modelgluePreservedState and _modelgluePreservedLog keys with this string when calling the session facade.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #301

    • Property priority changed from highest to normal
    • Property milestone changed from 2.0.1 to 3.2
    • Property severity changed from blocker to normal

  • Ticket #301 – description

    initial v6  
    1 The below components and files use the session scope directly when they should be using the ModelGlue_APP_KEY to group the sub application session variables to prevent collisions with other sub applications running in the same CF application. 
     1The below components and files use the session scope directly when they should be using the !ModelGlue_APP_KEY to group the sub application session variables to prevent collisions with other sub applications running in the same CF application. 
    22 
    33Currently two applications can run into each other with async requests or other state variables in the session in certain load situations. 
    44 
    55Affected Files: 
    6 ModelGlue.unity.eventrequest.EventContext 
    7 ModelFlue.unity.statebuilder.StateBuilder 
    8 ModelGlue.unity.framework.ModelGlue 
    9 ModelGlue.unity.loader.FrameworkLoader 
    10 ModelGlue/unity/ModelGlue.cfm 
    116 
    12 The files should be using session[ModelGlue_APP_Key] instead of session, which requires some minor changes to the ModelGlue component. 
     7!ModelGlue.unity.eventrequest.!EventContext 
    138 
    14 I suggest adding a method to ModelGlue.unity.framework.ModelGlue: 
     9!ModelFlue.unity.statebuilder.!StateBuilder 
     10 
     11!ModelGlue.unity.framework.!ModelGlue 
     12 
     13!ModelGlue.unity.loader.!FrameworkLoader 
     14 
     15!ModelGlue/unity/ModelGlue.cfm 
     16 
     17The files should be using session[!ModelGlue_APP_Key] instead of session, which requires some minor changes to the !ModelGlue component. 
     18 
     19I suggest adding a method to !ModelGlue.unity.framework.!ModelGlue: 
    1520 
    1621{{{ 
    … …  
    3035}}} 
    3136 
    32 Then the EventContext and StateBuilder components can use variables._framework.getSessionScope() to access the currently active session and ModelGlue.cfm can use _ModelGlue.framework.getSessionScope(). Of course the ModelGlue component can just use getSessionScope() directly. 
     37Then the !EventContext and !StateBuilder components can use variables._framework.getSessionScope() to access the currently active session and !ModelGlue.cfm can use _ModelGlue.framework.getSessionScope(). Of course the !ModelGlue component can just use getSessionScope() directly. 
    3338 
    34 The ModelGlue.unity.loader.FrameworkLoader component should also be changed to use the below code instead of generating a random key with CreateUUID(), then adding and deleting it. I doubt very much that there will ever be a collision with the UUID, but using a simple structKeyExists() removes that chance entirely, and also removes 2 function calls and one local variable! 
     39The !ModelGlue.unity.loader.!FrameworkLoader component should also be changed to use the below code instead of generating a random key with CreateUUID(), then adding and deleting it. I doubt very much that there will ever be a collision with the UUID, but using a simple structKeyExists() removes that chance entirely, and also removes 2 function calls and one local variable! 
    3540 
    3641{{{