How to... Devart.Data.Linq.DataContext in Web Sessions

[Ekki]

Hi,

this is probably badly placed as maybe not specific to PostgreSQL. But didn't find a better forum...

I develop a medium-complex ASP.NET Web forms application with DevExpress Web Forms on the UI side (doesn't matter I guess)

Currently I put my Devart.Data.Linq.DataContext's (I've usually two of them) into the session state. This works just perfect... mostly... Sometimes, however, if initial (with regard to the page's life cycle) operations take a little bit longer, or if there was some time of user in-activity, the access to the context(s) fail(s) (call A). If I reload the page again, it's working again (call B). Inside the page's init I call some context function.

So it seems the context was in some invalid state in call A, then probably restored and available in call B.

(1) Does this make any sense? Is there something like a 'sleeping context'?

(2) Regardless my specific problem, what is best practice for dealing with Context in the scope of Web Forms? Is it correct to store them in the session state?

(3) For the next time, what is the right forum for such issues?

Thx ia,

Ekki

[Ekki]

The issues under (1) have nothing to do with the Contexts and I cancel this issue herewith.

Looking for fdb to (2) and (3) though

Ekki

[MariiaI]

Consider using one DataContext instance for a single Web request. In this case, if in this single Web request you query database several times, this should improve performance due to rarer context initializations.
We don't recommend to use one DataContext for one session, due to the fact that session can take quite a long time and may contribute to work with outdated data, etc.
The context lifetime is discussed, e.g., here (see the arguments for the 'per-request' approach in the second answer; this is about EF, but the same principles are used for LinqConnect):
http://stackoverflow.com/questions/2724 ... t-re-usage.

Please also refer to http://forums.devart.com/viewtopic.php?f=1&t=25141.

The forum for discussing LinqConnect questions, bugs and suggestions is http://forums.devart.com/viewforum.php?f=31.

[Ekki]

Thanks a lot. Will consider all this carefully.

Just a last update on (1).

In the failure state the session entry holding the Context(s) is just removed while all session objects are there as expected. So there's something special with a Context. As I cannot find any place where a Context is removed from the session state it looks as the Context does remove itself from the Session state (which does not make sense), or some session life cycle detects the invalidity of the Context after coming back and thus removes it (what makes more sense).

If you have a comment on this I really would learn about. However, it's NOT mission critical as I'm changing the Context life cycle anyway (according to your recommendations).

Thx,

Ekki

[MariiaI]

If you have a comment on this I really would learn about. However, it's NOT mission critical as I'm changing the Context life cycle anyway (according to your recommendations).
Thx,
Ekki

Unfortunately, we cannot comment this behaviour without the test project, which demonstrates it.
If you have any further questions regarding working with LinqConnect, feel free to contact us.

[Ekki]

Meanwhile this has been resolved. On some very early place (Web Form SiteMaster) I did auto-setup a few session variables if not available. By not remembering this, I faced the strange issue that some state values were there while others weren't, as described above. So, no magic at all...

BR,

Ekki