Session_OnEnd event doesn't fire

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
Tue Apr 13 10:54:32 CDT 2004

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?

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/


"Patrick" <xxx@xxx.xxx> wrote in message
news:OcHKX6WIEHA.3556@TK2MSFTNGP10.phx.gbl...
> 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 ?
>
>

Patrick
Tue Apr 13 11:17:15 CDT 2004

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]" <aaron@TRASHaspfaq.com> a écrit dans le message de
news:%231XRe%23WIEHA.1608@TK2MSFTNGP11.phx.gbl...
> 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?
>
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
>
> "Patrick" <xxx@xxx.xxx> wrote in message
> news:OcHKX6WIEHA.3556@TK2MSFTNGP10.phx.gbl...
> > 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
Tue Apr 13 11:32:34 CDT 2004

> 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
Tue Apr 13 12:09:31 CDT 2004

> 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 ?

Egbert
Tue Apr 13 12:17:30 CDT 2004

"Patrick" <xxx@xxx.xxx> wrote in message
news:OFyUELXIEHA.2688@tk2msftngp13.phx.gbl...
> 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)

Aaron
Tue Apr 13 12:15:43 CDT 2004

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.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/


"Patrick" <xxx@xxx.xxx> wrote in message
news:OQKXRoXIEHA.348@tk2msftngp13.phx.gbl...
>> 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 ?
>
>

Patrick
Tue Apr 13 12:34:20 CDT 2004

> 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
Tue Apr 13 12:36:01 CDT 2004

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


"Egbert Nierop (MVP for IIS)" <egbert_nierop@nospam.invalid> a écrit dans le
message de news:OtvVCtXIEHA.3848@tk2msftngp13.phx.gbl...
> "Patrick" <xxx@xxx.xxx> wrote in message
> news:OFyUELXIEHA.2688@tk2msftngp13.phx.gbl...
> > 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)
>

Bob
Tue Apr 13 12:38:55 CDT 2004

Patrick wrote:
>> 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 ?

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
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Patrick
Tue Apr 13 12:58:17 CDT 2004

thanks Bob
it is the second time you save me :-)

Now; let's code !

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> a écrit dans le message de
news:%23beW84XIEHA.2524@TK2MSFTNGP11.phx.gbl...
> Patrick wrote:
> >> 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 ?
>
> 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
> --
> Microsoft MVP -- ASP/ASP.NET
> Please reply to the newsgroup. The email account listed in my From
> header is my spam trap, so I don't check it very often. You will get a
> quicker response by posting to the newsgroup.
>
>