Session_OnEnd event doesn't fire

[Patrick]

Hi all.

I use global.asa to create (Session_OnStart) and delete (Session_OnEnd)
tables in my Access database.

To test it in Debug Mode in VS.NET 2003, i use a page that only contains
"Session.abandon" : Everything runs fine.

But when i connect normally to the web app, the tables are created bur never
deleted.
It looks like the Session_OnEnd event is never fired, neither with
"Session.Abandon" nor with the 20 minutes session timeout.

Can someone help please ?

 

[Aaron Bertrand [MVP]]

You will need a scheduled cleanup routine, since you can't rely on
session_onEnd to ever fire. http://www.aspfaq.com/2078

A better solution would probably be to use common tables for all users,
rather than create and drop tables for every individual session. Why do
these people need to have their data stored in separate tables?

 

[Patrick]

Thanks for your quick reply Aaron !

IF i understand well what is said on the page you mention, i need to use a
table that will store session IDs (plus some unique info) and the last time
they connected.
This table will be updated everytime the user connects to a page of my site.
Then i will use an external program (a service) that will run on the server
and checks for rows that have a "last connection time" field inferior to
current time more than 20 minutes (sorry for my bad english...)
Is that right ?

About my individual tables, i use it as temporary tables for complex
operations of search and sort of datas.
First i delete all records in the table and then i fill it and sort it with
many different queries.
These operations are inside transactions.
But because MS Access has no record level blocking, i feared to get errors
because of an exclusive lock when 2 users try to acess the same temporary
table at the same time.
That's why i use individual temporary tables.
If ever you think there is a better way to do this, your advice will be
welcomed.

See you

 

[Aaron Bertrand [MVP]]

Is that right ?

Yes, that's pretty much what I suggest.

About my individual tables, i use it as temporary tables for complex
operations of search and sort of datas.
First i delete all records in the table and then i fill it and sort it
with
many different queries.
These operations are inside transactions.
But because MS Access has no record level blocking, i feared to get errors
because of an exclusive lock when 2 users try to acess the same temporary
table at the same time.
That's why i use individual temporary tables.
If ever you think there is a better way to do this, your advice will be
welcomed.

Yes, have ONE table and have sessionID as a key. Then you can run queries,
delete, etc. where sessionID= instead of dropping and re-creating tables all
day.

A

 

[Patrick]

Yes, have ONE table and have sessionID as a key. Then you can run
queries,

delete, etc. where sessionID= instead of dropping and re-creating tables all
day.

But because of the page lock, isn't there a risk for a user to lock rows
that do not have the same SessionID ?

 

[Aaron Bertrand [MVP]]

No, that is the point of the WHERE clause. They will only deal with rows
that have a value representing THEIR sessionID. It would work best if you
have an index on that column.

Besides, you're using Access, after all. Should this locking issue really
be the primary focus of your concerns about performance? It certainly would
be low on my list.

 

[Egbert Nierop \(MVP for IIS\)]

Thanks for your quick reply Aaron !

IF i understand well what is said on the page you mention, i need to use a
table that will store session IDs (plus some unique info) and the last time
they connected.
This table will be updated everytime the user connects to a page of my site.
Then i will use an external program (a service) that will run on the server
and checks for rows that have a "last connection time" field inferior to
current time more than 20 minutes (sorry for my bad english...)
Is that right ?

But because MS Access has no record level blocking, i feared to get errors

It has ...
Depends how you open the recordset...

because of an exclusive lock when 2 users try to acess the same temporary
table at the same time.
That's why i use individual temporary tables.
If ever you think there is a better way to do this, your advice will be
welcomed.

ps:
better not rely on Session.SessionID since this is not unique. Better create
your own cookie that is garantueed to be unique.
For instance http://www.nieropwebconsult.nl/download/unique.zip (including
sourcecode)

 

[Patrick]

Besides, you're using Access, after all. Should this locking issue really

be the primary focus of your concerns about performance? It certainly would
be low on my list.

It is not my primary focus, but before using individual tables, i used the
same table without SessionID row.
But i had "exclusive lock" errors when 2 users write/delete in the same
table.
I hoped transactions would solve the problem by putting users in a sort of
queue till the end of the lock. I don't where that idea came from (need some
rest for sure !). Of course it didn't work.
I was not sure that using a sessionID column as a key would solve that
problem.

But i'll try !
Thanks again Aaron

 

[Patrick]

Thanks for your reply Egbert !
I'll try your code to use my own unique identifier

 

[Bob Barrows [MVP]]

But because of the page lock, isn't there a risk for a user to lock
rows that do not have the same SessionID ?

Yes, since multiple rows will be contained by a single page, and Jet uses
page-locking, there is a slight possibility of that occurring, especially if
you have the table indexed to create a "hot spot" at the last page of the
table where all new records will be inserted, and you have a lot of users
attempting simultaneous inserts.

You can minimize the potential impact of these page locks by
1. Most important: keep transactions short by using read-only recordsets for
data retrieval and INSERT,UPDATE,DELETE queries for data modification. Also,
open your connections late (immediately before they are needed) and close
them early (as soon as you no longer need them)
2. If deadlocks are still occurring, use a field (or fields) for your
primary key that will assure that consecutive session id's will not be
stored consecutively
3. If it is still a problem, pad your records so that each page only
contains a single row of data. Each page is 2K, so as long as you ensure
that each row of data contains a little more than 0.9K, you will cause each
row to occupy its own page.

With a well-designed application, you should not have to worry about page
locks impairing user activity unless you are dealing with hundreds of users.

Bob Barrows

 

[Patrick]

thanks Bob
it is the second time you save me

Now; let's code !