![]() | |
![]() |
| | Thread Tools | Display Modes |
#11
| |||
| |||
|
|
Curt wrote: One thing I learned on Friday about this problem. The sessions do complete and disappear immediately when you are using a winform app. It appears to only be when you are linking in from a web page that they hang around. The IBM Rep had me run one of the samples that came with UniDK and it worked perfectly. It was doing nothing differently than I was in my web app, 'cept mine was a web app. Oh boy, here is a dump of thoughts, hope it makes sense. A thick client usually makes a persistent connection for one user, and goes through a nice wrapup process when the user closes the app. A thin client needs to hit and run much faster than a thin client. Theory #1 is that if you are trying to instantiate and then terminate a session within a single web session, that there isn't enough time for the close to occur before the client destructs. That could leave the server trying to close a connection without a client, and leave it in a hung state. Theory #2: the fact that your connection seems to wrap itself up in 30 minutes reminds me of the TIME_WAIT condition of sockets. This is a perfectly normal condition but some people (and programs) insist on trying to brutally terminate a process if it doesn't go from LISTENING or ESTABLISHED to dead within some number of seconds. I'm guessing that the code is not wrapping itself up for some reason and that it's remaining in a TIME_WAIT condition. Theory #3: If you're using ASP or ASP.NET then _where_ and _when_ you instantiate, store, and destroy your connection objects is critical. Some people instantiate a new DBMS connection on every transaction, which (per theories 1 and 2) will eventually leave the server in a wierd state. Some people handle everything in Session State, others in Application State. There are trade-offs for both. Theory #4: Curt, you didn't say so, but if you are using VB6 with ASP, for example, objects don't clean up their own memory, and if you just null a DBMS object (for whatever reason), you might be leaving a memory reference hanging. In .NET, most objects are cleaned up properly through garbage collection, but there are some classes that do not inherit from IDisposable which must be wrapped up manually - otherwise you have the same hanging problem. A series of ASP.NET transactions that instantiates objects without wrapping them up is bound to result in issues like this. I have no idea if the classes of UO.NET inherit from IDisposable. Even if your own code implements the Dispose pattern and use class Destructors, garbage collection is not guaranteed to happen immediately, thus leaving the possibility of objects hanging around when they shouldn't, or not being properly wrapped up when you expect. |
![]() |
| Thread Tools | |
| Display Modes | |
| |