John,
Perhaps you could clarify your requirements. The title of the original post
refers to failover of stateful session beans, while your recent message says
you want failover for an object "shared by many clients".
If it is the latter you are after, perhaps an Entity Bean or an object
backed up by a direct Java persistence mechanism is what you are looking
for?
Regards,
-Chris.
> -----Original Message-----
> From: John Hogan [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 4:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: failover of stateful session beans in WebLogic
>
> Thanks for the response Bill. The servlet session is not that well suited
> for a particular need we have because it is user specific. We need
> failover
> protection for an object shared by many clients.
>
> JohnH
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> Sent: Tuesday, April 18, 2000 3:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: failover of stateful session beans in WebLogic
>
>
> while looking a the docs I noticed something that caught my attention
> before:
>
> <web-logic-docs>
> By embedding a simple Java expression in the WLQL string, you can convert
> the supplied maxBal value to another currency before querying the RDBMS.
> For
> example, if maxBal is supplied in U.S. dollars and the conversion rate to
> pounds is 1.6483, you can use a simple expression to multiply the value:
> <finder>
> <method-name>findSomeAccounts</method-name>
> <method-params>
> <method-param>double</method-param>
> <method-param>string</method-param>
> </method-params>
> <finder-query>(& (< balance $0) (= owner $1))</finder-query>
> <finder-expression>
> <expression-number>0</expression-number>
> <expression-text>@0 * 1.6483</expression-text>
> <expression-type>long</expression-type>
> </finder-expression>
> </finder>
>
> In the above example, $0 is replaced by the Java expression @0 * 1.6483,
> which multiplies the value of maxBal by 1.6483. Because the EJB provider
> did
> not override the value of $1, WLQL maps $1 to the second parameter in the
> finder method signature, ownerID.
>
> A more advanced version of this finder could use Java to determine the
> conversion rate when converting maxBal:
> <finder-expression>
> <expression-number>0</expression-number>
> <expression-text>@0 *
> Double.parseDouble(System.getProperties().get("rate.pounds.dollars"))</exp
> re
> ssion-text>
> <expression-type>long</expression-type>
> </finder-expression>
>
> </web-logic-docs>
>
> I previously posted a message regarding improving and standardizing the
> finder syntax and was hoping for some feedback but alas none came. So I
> will
> *ignite* the issue again in this thread. Question: Is it just me but have
> the web logic guys just totally lost it. I am all for impoving the
> capabilities of the syntax like accessing a field within an object passed
> across as a parameter (based on java beans design pattern) but I think we
> are starting to push things just the the edge of silliness when we allow
> for
> the syntax to include :
> Double.parseDouble(System.getProperties().get("rate.pounds.dollars"))
> while
> still keeping the ridiculus prefix notation : >(& (< balance $0) (= owner
> $1)). Maybe I am old fashion but should not the finder syntax reasonable
> SQL
> considering that most ejb installations will have a relational database
> backend and most deployers would have knowledge of this over Java's api. I
> think the web logic server team's time would have been better spent in
> getting rid of the crappy prefix syntax - *we are not computers and do not
> process instructions this way*.
>
> To the web logic users who have used the features mentioned above. Could
> you
> tell me why not include the * 1.6483 in the original query syntax is this
> some limitation which was addressed in this convulated way or just an
> example demonstrating a unwarranted feature.
>
> William Louth
>
> > -----Original Message-----
> > From: Louth, William (Exchange)
> > Sent: Tuesday, April 18, 2000 8:29 PM
> > To: 'A mailing list for Enterprise JavaBeans development'
> > Subject: RE: failover of stateful session beans in WebLogic
> >
> > as per the web logic 5.1 documentation
> >
> > http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html
> >
> > ===========================================
> > Stateful session EJBs
> >
> > Stateful session EJBs can utilize cluster-aware home stubs by setting
> > home-is-clusterable to "true." This provides failover and load balancing
> > for stateful EJB lookups. Stateful session EJBs cannot utilize
> > replica-aware EJBObject stubs, and WebLogic Server does not provide
> > failover services for method calls to stateful session EJBs.
> >
> > If you require cluster failover services for stateful objects, consider
> > implementing the stateful session EJB as a servlet. Servlets can
> maintain
> > state through failover in a cluster using either JDBC, an operating
> system
> > file, or directly in memory. See Using session tracking from a servlet
> for
> > more information.
> >
> > ===========================================
> >
> > I do not have any idea if there are plans. I suspose this will come with
> > the next release possibly next year (ejb 2.0) since this release has
> still
> > to come out of beta.
> >
> > William Louth
> >
> > -----Original Message-----
> > From: John Hogan [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 18, 2000 8:00 PM
> > To: [EMAIL PROTECTED]
> > Subject: failover of stateful session beans in WebLogic
> >
> > All,
> >
> > This feature seems to be missing from WebLogic and their documentation
> > suggests achieving failover protection using servlet/session. Am I
> > understanding this right, and does anyone have information on WebLogic's
> > plans to support stateful session bean failover? Thanks.
> >
> > JohnH
> >
> >
> ==========================================================================
> > =
> > 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".
>
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
