--- [EMAIL PROTECTED] wrote:
>
> IMHO it would be a mistake to write a session
> manager using the same
> abstractions as in a servlet container - after all
> the task is to store
> data and the requirements are pretty specific )
>
I'd like to poke my $.02 in and say I totally agree
with Costin. The only 'connection' required between
the servlet container apis and persistent session
management is state maintenance, which can be
encapsulated in some sort of session identifier (i.e.
cookie typically) which can be built independent of
the actual container by using the standard servlet
APIs (v 2.2 is sufficient). Other than that, the
actual implementation of a persistant session
managment API does not have to have anything to do
with the servlet container or even the servlet API.
I have built such a beast and it is, as Costin
advocates, independent of servlet container. It is
proprietary, so I can't give it to the project, but
the basic principal is simple:
1 - Use the standard servlet API's to establish a
'session identifier' (cookies work fine for 90% of the
browser world out there).
2 - use this as a key into your persistant session
store.
Naturally, there are some other details involving
assertaining the 'active' or inactive state of the
session, time out of session ids,authentication
controls, etc., but even all that does not have to
depend on the servlet container. You should come up
with a scheme that is pluggable as to where the actual
data is stored (i.e. disk files vs (shared) RDBMS vs
whatever).
Just my $.02.
Mel
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
