Alex Gleyzer wrote:
> 2. Using cookies(???). Our official policy is to use URL-rewriting,
> since many potential customers still use old browsers.
Most servlet engines (including the WebLogic server) provide URL-rewriting as an
alternative 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.
Tengah (now BEA Weblogic) can be used as a servlet engine for Apache, IIS or NES
(and FastTrack actually). You are therefore free to use any front line HTTP
server you like.
> I also was unable to find details about how often HttpSession is synched > with the
>db.
Since the HttpSession is an EJB it is also a JTS resource and updates to its
state are sent to the db on tx boundaries. The EJB is deployed TX_REQUIRED so
if there is no current tx a new tx will be started (and subsequently committed)
for each change.
>
> 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:
>
> 1. Is it possible to seamlessly substitute "standard" HttpSession with
> our custom one which would talk to the bean?
The JSDK specification doesn't provide for this and to my knowledge no servlet
engine vendor provides this extension.
> 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?
This is handled by the session mechanism of the servlet engine.
> 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?
Our current implementation provides very reliable fail-over support as all data
is immediately put on disk. It also scales well and has been successfully
deployed by a number of customers.
In our 4.1 release we will be offering sessions which are pair-wise replicated
in main memory across WebLogic servers in a cluster. This option will provide
excellent scalability and improved efficiency but slightly less reliable
fail-over. Specifically if two WebLogic servers in a cluster fail within a
short time the session data could be lost).
Additionally with the 4.1 release we will be providing smarter plug-ins for IIS
and NES which will route every request within a particular session to the same
WebLogic server in a cluster allowing for more efficient caching (the session
data is still available on every WebLogic server in the cluster, but at a
slightly higher cost than on the primary server for the session). These
plug-ins work even if the HTTP requests are being load balanced among several
HTTP servers. The new plug-ins also load balance the creation of new sessions
so as to distribute the load among WebLogic servers.
I hope this message provides you with the information you need. Feel free to
email me directly if you require more.
> 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?
The servlet engine typically takes care of this. If you were to do you're own
implementation you'd of course need to handle this directly. If implemented
inside of WebLogic I'd recommend using our timer services rather than dedicating
a thread which would just spend most of its time waiting.
Cheers!
Adam
--
WebLogic is now part of BEA Systems: http://www.beasys.com/
===========================================================================
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".
