RE: Session Timeout listener (was: RE: [RT] The API for the request object)

["Hunsberger, Peter" <Pe...@STJUDE.ORG>]

Colin Paul Adams <co...@colina.demon.co.uk> writes:

<snip>flow listener discussion,/snip>
> 
> I've just read this thread, because I have been trying to 
> work out how to implement pessimistic locking within cocoon. 
> A problem is how to close a database transaction if the user 
> simply walks away from the computer for a few hours, in the 
> middle of a transaction. Session timeout will close the 
> session, but a session listener is needed to then go and 
> rollback the database transaction (or any other such resources held).

Maybe I'm missing something, but why aren't you setting your database
transaction timeout limit to something just a bit larger than the
session timeout?  Or, alternatively, if you're using EJB's, set your
container TX timeout?  In either case the appropriate catch clause in
your code can then do resource clean up as needed...

Berkeley DB XML (Was: Session Timeout listener)

[Colin Paul Adams <co...@colina.demon.co.uk>]

>>>>> "Sylvain" == Sylvain Wallez <sy...@apache.org> writes:

    Sylvain> Or you can also add store in a session attribute an
    Sylvain> object implementing
    Sylvain> javax.servlet.http.HttpSessionBindingListener that will
    Sylvain> be called whenever the session expires. This allows to
    Sylvain> perform any cleanup that you need.

    Sylvain> Remember however, that holding costly resources like DB
    Sylvain> connections between request is generally considered bad
    Sylvain> practice in webapps, because of this very problem of
    Sylvain> detecting that a user has left.

I don't see why it should be considered bad practice.
If you set a session timeout, then it's just a case of balancing the
amount of time needed for a user to reasonably complete a transaction,
against the extra memory used.
Of course, it won't scale terribly well, but under the conditions
assumed for optimistic locking, this can't be a problem anyway. And
this is a much more user-friendly approach then optimistic locking.

But rather than use HttpSessionBindingListener, I've decided to use
Berkeley DB XML.
Anyone any experience of this with Cocoon?
-- 
Colin Paul Adams
Preston Lancashire

Re: Session Timeout listener (was: RE: [RT] The API for the requestobject)

[Ralph Goers <Ra...@dslextreme.com>]

I was going to suggest HttpSessionBindingListener as well.  In fact, it is
kind of pointless for Cocoon to implement a SessionListener since it would
have to do it through a SessionBindingListener anyway.

Ralph


Sylvain Wallez said:
> Hunsberger, Peter wrote:
>
>
> Or you can also add store in a session attribute an object implementing
> javax.servlet.http.HttpSessionBindingListener that will be called
> whenever the session expires. This allows to perform any cleanup that
> you need.
>
> Remember however, that holding costly resources like DB connections
> between request is generally considered bad practice in webapps, because
> of this very problem of detecting that a user has left.
>
> Sylvain
>
> --
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>

Re: Session Timeout listener (was: RE: [RT] The API for the request object)

[Sylvain Wallez <sy...@apache.org>]

Hunsberger, Peter wrote:

>Colin Paul Adams <co...@colina.demon.co.uk> writes:
>
><snip>flow listener discussion,/snip>
>  
>
>>I've just read this thread, because I have been trying to 
>>work out how to implement pessimistic locking within cocoon. 
>>A problem is how to close a database transaction if the user 
>>simply walks away from the computer for a few hours, in the 
>>middle of a transaction. Session timeout will close the 
>>session, but a session listener is needed to then go and 
>>rollback the database transaction (or any other such resources held).
>>    
>>
>
>Maybe I'm missing something, but why aren't you setting your database
>transaction timeout limit to something just a bit larger than the
>session timeout?  Or, alternatively, if you're using EJB's, set your
>container TX timeout?  In either case the appropriate catch clause in
>your code can then do resource clean up as needed...
>  
>

Or you can also add store in a session attribute an object implementing 
javax.servlet.http.HttpSessionBindingListener that will be called 
whenever the session expires. This allows to perform any cleanup that 
you need.

Remember however, that holding costly resources like DB connections 
between request is generally considered bad practice in webapps, because 
of this very problem of detecting that a user has left.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Session Timeout listener (was: RE: [RT] The API for the request object)

[Colin Paul Adams <co...@colina.demon.co.uk>]

>>>>> "Colin" == Colin Paul Adams <co...@colina.demon.co.uk> writes:

    Peter> Maybe I'm missing something, but why aren't you setting
    Peter> your database transaction timeout limit to something just a
    Peter> bit larger than the session timeout?

    Colin> Well, I guess this is fine for a database server dedicated
    Colin> to the application (which is OK for my usage).  But it's
    Colin> not a general solution to resources being held by sessions.
    Colin> I thought I'd raise the issue while listeners were being
    Colin> discussed.

In fact, checking the documentation for postgresql, it doesn't have
transaction timeout, only statement timeout, which certainly isn't adequate.
-- 
Colin Paul Adams
Preston Lancashire

Re: Session Timeout listener (was: RE: [RT] The API for the request object)

[Colin Paul Adams <co...@colina.demon.co.uk>]

>>>>> "Peter" == Hunsberger, Peter <Pe...@STJUDE.ORG> writes:

    Peter> Colin Paul Adams <co...@colina.demon.co.uk> writes:
    Peter> <snip>flow listener discussion,/snip>
    >>  I've just read this thread, because I have been trying to work
    >> out how to implement pessimistic locking within cocoon.  A
    >> problem is how to close a database transaction if the user
    >> simply walks away from the computer for a few hours, in the
    >> middle of a transaction. Session timeout will close the
    >> session, but a session listener is needed to then go and
    >> rollback the database transaction (or any other such resources
    >> held).

    Peter> Maybe I'm missing something, but why aren't you setting
    Peter> your database transaction timeout limit to something just a
    Peter> bit larger than the session timeout?

Well, I guess this is fine for a database server dedicated to the
application (which is OK for my usage).
But it's not a general solution to resources being held by sessions.
I thought I'd raise the issue while listeners were being discussed.
-- 
Colin Paul Adams
Preston Lancashire