It does seem like you've made this whole thing overly complex. Are you sure
that you cannot just split the state between a cluster aware HttpSession and
the database? Have you prototyped it and shown you application will be too
slow if it uses the database?
Cheers
-----Original Message-----
From: Kevin Bedell
To: [EMAIL PROTECTED]
Sent: 5/26/01 10:13 AM
Subject: Re: stateful session bean failover via jndi?
Using Session failover provided by the container
certainly seems like a more practical approach - as
long as your container provides it.
One of the issues you'll find here is that the session
bean you're describing will inevitably not encapsulate
the entire "conversational state" of the users. That
is, there will be other session objects/information
that will need to be managed/persisted.
Writing all this to LDAP may not be the best approach
- it may be better to map the user bean in ldap
containing very basic information that is not updated
(name, userid and not much more) and then persist
other user/session information in a database. Or leave
LDAP behind and persist everything in the database.
Inserting a significant amount of information in LDAP
or replicating a significant amount of session-scoped
information between JVM's or App Server instances may
become a performance bottleneck sooner than leveraging
a database.
--- Tinou Bao <[EMAIL PROTECTED]> wrote:
> I'm not sure if I'm completing understanding your
> message but the app
> servers I am familiar with provide http session
> failover, either persisting
> the http sessions or replicating them in memory when
> running in cluster.
>
> --
> Tinou Bao
> www.tinou.com
>
> ----- Original Message -----
> From: "Rhodes, Phillip C."
> <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 25, 2001 6:17 PM
> Subject: [EJB-INT] stateful session bean failover
> via jndi?
>
>
> > I have a stateful session bean that represents a
> logged in user. The
> > client that creates the stateful session bean is a
> servlet. My worry is
> > that if the container that is holding this servlet
> goes down, I will lose
> > the session bean reference. The user would then
> have to re-authenticate.
> >
> > In order for this to not happen, when the bean is
> created, I put the user
> > object into jndi, bound to the sessionid of the
> http session of the user.
> I
> > intend to make my jndi tree a netscape ldap server
> (replicated)
> >
> > Now if the client would go down, a new client(a
> different servlet
> container)
> > would receive a request (with the session id), if
> it did not have a handle
> > to the user stateful bean (stored in HTTPSession),
> it could call the
> > UserHome object, with the session id. The user
> home object could then do
> a
> > JNDI lookup, get the user object and re-create the
> bean.
> >
> > I am trying to break the tie between the
> > HTTP server, HTTP servlet container and the EJB
> container, so that if any
> > part goes down, the user's session bean is not
> lost and can be re-created
> or
> > retrieved with the session id token.
> >
> > In addition to the case of an servlet container
> going down, this protects
> me
> > in the case that an application server goes down.
> >
> > I would like to be shoot down!! I appreciate some
> constructive criticism!
> > Thanks,
> >
> > Phillip
> >
> >
>
========================================================================
===
> > 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".
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.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".
===========================================================================
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".
