Session management

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Session management

dtrussardi@tiscali.it
Hello All,

i work with VW7.4.1 and seaside support.
 

I have create a "unregistered" method to manage the web Session close operation.
 
 
About session Lukas write:
   
<Old sessions are only pruned when they have timed-out and new ones are
<created. So this doesn't happen too often.

At the "unregistered" method i'have add :
        Transcript show: 'Web session ........ closing '.

And it write right line in the transcript when "unregistered" method is call for old session.
 
But the MyWASsession instance is not 'close'.
 
Question A)
                       Because the MyWASession instances increasing?
                        What do i do to "erase"  they?
                        Because with 80 old session  the system go in loop ?
 
Question B)
                        I can manage the old session with more precision?
                        I'm interested to close the database connection in real time, when the session " go in time-out " .
                        Not do it later.
 
Any pointers would be greatly appreciated!

Thank,

Dario Trussardi Romano
 
 

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Session management

Ramon Leon-5
> But the MyWASsession instance is not 'close'.
>  
> Question A)
>                        Because the MyWASession instances increasing?
>                         What do i do to "erase"  they?
>                         Because with 80 old session  the
> system go in loop ?
>  
> Question B)
>                         I can manage the old session with
> more precision?
>                         I'm interested to close the database
> connection in real time, when the session " go in time-out " .
>                         Not do it later.
>  
> Any pointers would be greatly appreciated!
>
> Thank,
>
> Dario Trussardi Romano

You probably don't want to hold one db connection per session, and you're
seeing why, it's not really scaleable and sessions take too long to timeout.
Try something like this instead, which is a db connection per request.
Override #responseForRequest: on your session class and setup the connection
before processing the request.

responseForRequest: aRequest
    self connection: self getConnection.
    ^[super responseForRequest: aRequest]
     ensure:[self connection close]

If you want to get fancier, you could build your own connection pool and
avoid the cost of creating a new connection on every request, something
like...

responseForRequest: aRequest
    ^ConnectionPool
        user: 'x'
        password: 'xxx'
        server: 'localhost'
        database: 'someDatabase'
        with: [:conn |
            self connection: conn.
            super responseForRequest: aRequest]

Where you pass a block a pool that stores lists of connections by its
credentials, it then grabs a connection from the pool, passes it through
your block, returns it to the pool, and then returns the result of the
block, which is in this case, the response.  You could use a SharedQueue
inside the pool to ensure thread safety, or just dictionaries and ordered
collections and do the locking yourself.

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside