Just got round to picking off some low-hanging fruit in our app. One bug in particular that has been hanging in there is that I sometimes get stuff left in a database from a session that has not crashed - it looked for all intents and purposes as if the destructor method of a particular class was not being called.
Turned out I was right - but for the wrong reason
Seems as if you execute the QUIT statement, then the destructor method is not called on any object currently in memory,
Now that I know this, I can fix it !
Just a FYI if you didn't already know. If you did already know, make an old man happy and keep it to yourself Unless you are particularly cruel and want to tease
Not to tease ... but why would you have a design that required firing destructor to clean up things in the database? Clean up local stuff that might otherwise contaminate a local session, sure, but stuff written to the database that needs to be backed out by the destructor?
yay! I win my bet with myself.
Every time a user logs on, they get a new sessionguid - this guid is used to create a temporary account in a IM database. The singleton object is meant to clean up after the session to remove any session-state that is lingering. I just assumed (yes, my fault) that the destructor would always get called.
I guess the risk of that approach is now apparent ...
tamhas wrote:
I guess the risk of that approach is now apparent ...
Meh, not so sure.
I need the sessionguid to record each session of work in a history table. I also need to be able to have multiple sessions in the IM for a single user (they may login more than once to the application and the client does not want separate logins) so I need to uniquely identify a session.
If the session crashes (this is windows, after all), how else do I know which temporary ID's in the IM I need to delete without storing a record of them somewhere ? It's like a cookie for my app.
Just off hand, my first thought would be a session manager to handle the IDs for everybody. Then, database issues would relate only to the session manage crashing and, if it crashes, you know you have to clean out and start fresh anyway. Some form of keep alive could tell the session manager when the session had disappeared unexpectedly and the session manager could clean up. LRU management of current session would mean that one only needed to even try the keep alive for sessions that hadn't been heard from in a while while various processes could notify the session manager that a session had had new activity.
Just a FYI if you didn't already know. If you did already know, make an old
man happy and keep it to yourself Unless you are particularly cruel and want
to tease
I'd run this by TS. I'd expect the session to clean up after itself nicely.
-- peter
Julian, how is your singleton implemented? Is it a class with just static methods? In that case there is just a static constructor, but no destructor. So there would be nothing to be executed at session shutdown.
I've implemented a quick sample using a classical singleton pattern (a class with a static GetInstance() method and a private static variable that holds the reference to the one and only instance and all other members a not static). The destructor of the singleton instance will be executed even when I leave the session with the QUIT statement.
See attached sample.