In 2012r2.1, I have code that runs on the server but is initiated on a WebPage. When the server finishes, it sends a message to the WebPage.
When the process is initiated, the WebPage sends a Session to the server.
When it’s time to notify the user, the Server does something like this:
Dim wcContext as WebSessionContext
wcContext = New WebSessionContext( wsPassedInSession ) //This was passed in by the WebPage and stored.
Then, I can call Session functions and properties normally.
In 2012r2.1 this works fine, but 2013r1 Session is Nil even after I set the context.
Feedback item 27067 seems to be about this problem, but the described workarounds don’t work for me.
This certainly explains why 13r1 breaks my project.
Would you expect this workaround to be successful?
- Have the WebPage pass in the Session.Identifier to the server-side code.
- On the server side, scan the App.Session array for the matching Session.Identifier
- Once a match is found, call whatever Session-based function you need to call.
This process seems to work but it appears something causes the Session to totally reset.
[The blog post suggests using a WeakRef to later reference the WebPage, but I actually need to call a function in the Session from the server.]
Perhaps a WeakRef to the WebSession itself, then?
I experimented with WeakRef’ng the Session but when I did this on the server:
the compiler refused to recognize my function.
It looks like I can work around the WebSessionContext by passing in a Session Identifier and matching it to one of the Sessions in App.SessionCount. From the server side, I can then call the Session function and step through it in the debugger. It seems like the server is finding the right Session.
But when the Session function starts communicating with the WebPage, something goes wrong. The session just dies and this is logged:
Warning: No Session object in context
Then a new Session is created which shouldn’t be happening.
I’m going to try and duplicate this design in 12r2.1 and see what happens. Perhaps I am encountering two different issues here.
Change of plans, I am actually going to wait for the next release instead of spending a lot of time in 12r2.1 and 13r1 trying to get around this.
[quote=19822:@Russ Tyndall]I experimented with WeakRef’ng the Session but when I did this on the server:
the compiler refused to recognize my function.[/quote]
What if you add a WebSession subclass, MySession for your custom methods and set it as the Super for Session. Then this code might work (I’m not at a computer to test):
A lot of work has been done on WebSessionContext for 2013r2. Try this again when it’s released.
Paul: Your idea of subclassing the Session fixes the problem in which the server cannot talk to the Session. However, the secondary problem in which the Session dies while it is talking to the WebPage remains.
Greg: I will fire this thread back up when r2 comes out, and provide a report on how these issues are affected.
Here’s my report after testing my earlier reported problems in 2013r2:
For my implementation, WebSessionContext seems fixed — my app works fine under 13r2 as well as it did in 12r2.1. So I do not have any problems with my own project.
But my attempts to design a workaround for the 13r1 problems seem to point to some type of problem. While trying to implement a workaround for the now fixed WebSessionContext issue in 13r1, I tried a design like this:
I would pass in the right SessionID (strSessionID) and examine the App.Session array for the right ID. Once I have the right Session,
I would call a function in the Session.
[code]Dim intNoOfSessions as Integer = 0
intNoOfSessions = App.SessionCount
For intCounter as Integer = 0 to intNoOfSessions - 1 Step 1
If app.SessionAtIndex( intCounter ).Identifier = strSessionID Then
//This seems to be the session that called for the Download job.
Session( app.SessionAtIndex( intCounter ) ).funNotifyUserDownloadReady( _
In 2013r1 and 2013r2 what I am finding is that when funNotifyUserDownloadReady() is called using the SessionAtIndex syntax, the right Session function is called. The debugger permits me to step through the Session function But then something causes the Session to die. (It might be useful to know that the Session function is calling back to a WebPage.)
So, to summarize: My app works fine with the WebSessionContext fixes (thank you!) but the app seems to behave “badly” when I use the described design to reference the proper Session. Should the two methods of accessing the Session work equally well? If so, something is wrong.