Okay, here's a tricky one. It's about sessions launched in parallel and how things get mixed up.

We have a report that starts three fexes in parallel in three different iframes.
Each fex creates some data in the FOCCACHE and starts a launch page using that data in a dropdown list. Frequently, these reports show empty dropdown lists. Odd...

We have determined the cause, by issuing WHENCE on the FOCCACHE master in each fex.
After a reload of the page, the drilldown lists are filled and each WHENCE is showing the same FOCCACHE directory. That is good.
With browser cookies erased and a clean cache - and hence a new session - we see three different FOCCACHE directories from the output of that. Not good.

Here's my hypothesis:
The FOCCACHE directory for each fex is determined by the WF server, based on a session created by _something_. Which piece of the puzzle that is is probably important, but I don't currently know which it is. Is it an HTTP session? Does the WF server handle its own sessions or is the WF client doing that?
And when is the session created? At the start of a procedure? When the FOCCACHE gets involved? At the end of a procedure?

Anyway...

Since the fexes are all launched from the same browser in parallel, each fex is the first in its session, creating three different sessions with three different FOCCACHE directories. Only one of these session ID's (probably the last one created) makes it to the web-browser and is used in all three launch pages.

Now normally that doesn't matter. However, these launch-pages read data from those FOCCACHE tables, and they do so using AJAX: Asynchronous Javascript And Xml.
As a consequence, the launch pages cannot find their files in the FOCCACHE, because they're looking in the wrong session's FOCCACHE directory, namely the directory belonging to the one session that the web-browser knows about.

Now for an attempt to a solution:
I already moved the launching of these three fexes into one parent fex, assuming that starting a fex creates a new session.
That did not help. Apparently the session does not get created at the start of a fex then.

If, on the other hand, sessions get created on completion of a fex, then the parent fex will be the first fex to complete, but the other fexes will already have started loading and will therefore create session id's of their own when they complete - and the last one to complete will determine the final session id...

*Groan*

This reminds me a bit of that situation where you put a new coat of lacquer on the floor and halfway the room you realise you started at the door... Somebody paint me an exit please!

This message has been edited. Last edited by: FP Mod Chuck,

Hi Web5622

In my opinion this is a case for techsupport. They are going to need fiddler2 traces etc to track the sessions.

Yeah, you're probably right. I was hoping that someone on this list had run into this before and worked out a solution; and there's still chance that happens, this thread is young.

One of the reasons I posted here first is that this is one of those types of problems that you aren't aware of unless you dig deep enough to find that something is wrong.

I think this is a design pattern that's becoming more common.
Most people would just reload the page, see their dropdown lists filled, shrug and blame the browser cache. And they'd be wrong for a change.

Strictly speaking, this opens up the possibility of session hijacking, especially in combination with ARP poisoning. That's a security vulnerability...

If that doesn't mean anything to you, don't worry, I only learned about that earlier this year in a security course

Do you need to create your in FOCCACHE? Why not store the files using FILEDEF in the same app directory? Then you could use that one and only one directory in your launch page.

Fernando

Unfortunately, different users get different data sets based on their access rights. They work in parallel too, so that would create conflicting writes for files of the same name. And that in turn causes agent crashes, empty reports, errors, etc.

You could get around that by randomizing the names, but you would need to pass those randomized names on to the launch pages, which is where the session comes into play again.

Basically, going that route, you're doing a whole lot of work that the FOCCACHE was designed for.

Or, the files could be written to a directory per user, but that puts a lot of strain on the PATH resolving logic in the server and generates a whole lot of files that would need cleaning up again. Not pretty...

Still, we hadn't considered that option yet, so thanks for the suggestion.

I think the solution to this problem is to somehow force the creation of a session before we're in parallel territory, but how we're going to achieve that I haven't figured out yet.

I've just found a similar issue.

We have a portal, with a parameter page, that drives three or more reports.

First run, each report gets a separate FOCCACHE folder.

Second run all the FOCCACHE writes go into the last one.

Hi A, ( wep )

Do you recall us having a similar issue?
Well, I fixed it.

Reading ( again ) what you did should actually work. At least for a user having only one browser.

I have just one question.

How to HOLD the data?

ON TABLE HOLD AS HOLD_MYDATA

or

ON TABLE HOLD AS foccache/HOLD_MYDATA

We need the use the last one otherwise it doesn't work.

And don't use -EXIT. This will kill the session.
And be carefull with HTMLFORM BEGIN / END...

Let me know.

Hi Dave,

I do indeed recall that. It's not that long ago that we visited your company with the user group

Maybe I don't understand your question correctly? I suspect this is no new information for you, but it can't hurt to reiterate a bit...

If you want to store the data in the FOCCACHE, you will need to either specify that explicitly using ON TABLE HOLD AS foccache/HOLD_MYDATE or, I suppose, by issuing APP HOLD foccache.
The latter seems a rather bad idea, to be honest... in my experience, storing things that you only need temporarily tends to bite you later on.

If you just use ON TABLE HOLD AS HOLD_MYDATA, then you are just creating a temporary HOLD file that is gone at the end of the (outer) procedure. That is always safe in this context; The problem doesn't occur until you try to retrieve the held data from some other procedure.
For example in the case of a launch page reading the held data to populate a control. If held temporarily only, instead of in foccache, the data is gone at that point and the control won't populate ever (which is worse than we get now).

The third option is to hold it in an APP directory, but then different users are writing to the same file in the same location and problems ensue.

You could modify the HOLD file names to make them unique across users, but then you're in for some fun trying to get HTML Composer to recognize where to read the data for its controls from; it's a different master for every user!

So as far as I can see, the options are:
1). Use foccache,
2). Don't retain data after the procedure exits,
3). Abuse an app directory and deal with the problems that causes somehow, or
4). Abuse an app directory and make hold filenames unique and then find some way to get HTML Composer to understand your intentions.

Option 1) seems to me to be the least hassle, but that brings us back to the problem that is the topic of this thread.


Regarding -EXIT and -HTMLFORM BEGIN/END, it's always good to remind people of that - it is somewhat surprising behaviour.
It's unfortunately not what bites us though; We can actually see the various HOLD files in their respective foccache directories in edatemp. We know, because we added WHENCE statements in our startup scripts for each of the fexes that we start in parallel. Their output gets echoed into the generated HTML source, hence we know exactly where the files get held.

To us the problem is pretty well-defined: the separate sessions that we started in parallel get smashed onto a single session once the HTTP request for the report completes. Presumably that happens because the browser knows about only a single session id; the last one assigned is the one it knows about. The other sessions just get orphaned.

The problem would be easy to solve if we could somehow start a session before that happens. In that case, the procedures we start in parallel would already be part of an existing session and they would therefore have the same foccache directory. Unfortunately for us, these procedures are started from an HTML page that's very close to the top of our portal hierarchy; I do by now have an idea of how to solve that, but I'm not yet sure of the full consequences, I seem to recall an elephant in that room...

A,

quote:

It's not that long ago that we visited your company with the user group

We do it like this.

-SET &RND = some_really_random_number;
-SET &HOLDFILENAME = 'foccache/H_' | &RND;

TABLE FILE ...
ON TABLE HOLD AS &HOLDFILENAME
END

-SET &&DUDE_WHERES_THE_DATA = &HOLDFILENAME

mind the && in the last parameter, it's global ( i.e. session bound ).


Because:
Although it's called a global parameter, it's not. It's available for the session.
And foccache/ files do NOT dissappear immediatly after the procedure is done.



So we had a .fex the makes a hold file based on whatever parameters the users wants.
We had a global parameter that contains the name of that file.

Any other frame will just have to:

TABLE FILE &&DUDE_WHERES_THE_DATA
....
END

Trick is...
...how to the other (i)frames know when it's ready.

They don't.


So we hyperlink the "run" button to the main .fex ( the one that generates the hold ) and direct to output to an empty frame

all other frame have reports : "reference an external procedure". And we set autoExecute to False.



...and the we include some nifty javascript code at the end of the first .fex that finds all iframes ( and excludes it self ) and executes all other frames.



...works like shine.