Alex,
Here is a perspective from an alternative vendor for you to consider...
> -----Original Message-----
> snip
> I'd like to use standard HttpSession classes from Java Servlet API, but
> I realize that standard implementation is:
>
> 1. Local to the server where servlets are running. We need to have them
> shared among all front boxes. We might also want to use our existing
> session tables in the database so servlets coexist with current CGIs.
>
GemStone/J provides a shared http session state mechanim which leverages
our Persistent Chache Architecture. Load balancing across multiple servlet
engines
can happen at every WEB hit, and session state is accessible on any engine
on
any.
> 2. Using cookies(???). Our official policy is to use URL-rewriting,
> since many potential customers still use old browsers.
>
Our bundled servlet engine (New Atlanta's servlet exec ) supports various
alternatives
to cookies.
> I found that WebLogic's implementation of HttpSession can use a JDBC for
> storing sessions, but then we'd need to use Tengah as our http server,
> and use their table structure. I also was unable to find details about
> how often HttpSession is synched with the db.
>
Our servlet engine is a WEB server plug-in. Use whatever web server you want
(NetScape, Apache or MS IIS).
> My solution is to have a bean-managed entity bean representing HTTP
> session in the EJB server, and have servlets talking to it. So here are
> my questions:
>
This is not the solution we provide, but then again it's already cooked, so
you
don't have to do anyhting. Just use the session state apis... The rest is
transparent.
> 1. Is it possible to seamlessly substitute "standard" HttpSession with
> our custom one which would talk to the bean?
>
This is what we have done, but I don't know the mechanisms.
> 2. How can I guarantee that there's only one instance of my HttpSession
> bean representing particular session? Is it done by the server already?
>
You would need a unique key of some sorts. We generate them for you, across
servlet engines.
> 3. What would be advantages in sticking with WebLogic's implementation
> of the HttpSession with JDBC persistence? Where could I find more
> information regarding how this option works?
>
I don't know, but the disadvantage is what you said earlier. Doesn't work as
a servlet
plug-in to a first class web server.
> 4. We also want to expire sessions, so there should be a thread/process
> doing that. What would be the best way to implement it, another client
> process, or maybe we could run it as a thread with weblogic's jvm. Is it
> possible?
>
We do this, there is a background daemon as you imagine.
> I'd appreciate any comments/pointers.
>
You can build it, or you can buy it ;-)
> Thanks,
> Alex
>
> --
> Alex Gleyzer email: [EMAIL PROTECTED]
> Boyle Software phone: (212) 596-2949
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
