if you want to use ejbs, have bean A publish a JMS message whenever it is changed, 
bean B is then a MDB that receives those
notifications, and does whatever it needs to then.  that way you have no polling.

hth
dim

----- Original Message -----
From: "Fabian Crabus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 25, 2002 3:04 AM
Subject: AW: Re: Implementing wait in EJBs



ok, don't use an ejb for this...
how about simple external java class (implemented as a startup class or whatever) 
which is
allowed to handle threads...

        -----Urspr�ngliche Nachricht-----
        Von: Sriphani Singaraju [mailto:[EMAIL PROTECTED]]
        Gesendet: Do 24.01.2002 16:11
        An: [EMAIL PROTECTED]
        Cc:
        Betreff: Re: Implementing wait in EJBs



        Actually, I should have been more specific. In my case, Bean A is a legacy 
component(Neither any assumptions nor any
tampering Bean A). So, I feel that the resources pointed to, may not be applicable for 
this. As Bean B, do I have any other options
than busy-waiting ??

        -----Original Message-----
        From: Fabian Crabus [mailto:[EMAIL PROTECTED]]
        Sent: Thursday, January 24, 2002 7:25 PM
        To: Sriphani Singaraju; [EMAIL PROTECTED]
        Subject: AW: Re: Implementing wait in EJBs


        You could try this:

        http://www.theserverside.com/patterns/ObserverPattern.jsp

        or you could use JMS:
        let Bean A notify Bean B of any state changes

        so indirectly Bean A activates Bean B

        How about this?


        -----Urspr�ngliche Nachricht-----
        Von: Sriphani Singaraju [mailto:[EMAIL PROTECTED]]
        Gesendet: Do 24.01.2002 14:23
        An: Fabian Crabus; [EMAIL PROTECTED]
        Cc:
        Betreff: RE: Re: Implementing wait in EJBs



                Hi Fabian,

                The scenario goes like this:

                Bean B invokes a method on Bean A (B is ignorant of the state of A)
                Bean B should try this repeatedly until the state of A is changed (to 
a state favourable for servicing Bean B's
request).

                I know it is a performance overhead, but, thatz how the business logic 
goes. For this case, I'm worried more abt
achieving this rather than the amount of time Bean B is blocked.

                Hope this makes my point clear!

                Regards,
                Sriphani.

                Any views expressed in this message are those of the individual
                sender, except where the sender specifies and with authority,
                states them to be the views of Huawei Technologies India Pvt. Ltd.

        
--------------------------------------------------------------------------------------------------------------------
        This email and any files transmitted with it are confidential and
        intended solely for the use of the individual or entity to whom
        they are addressed. If you have received this email in error please notify the
        originator of the message or [EMAIL PROTECTED]

        Any views expressed in this message are those of the individual
        sender, except where the sender specifies and with authority,
        states them to be the views of Huawei Technologies India Pvt. Ltd.

=========================
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".

Reply via email to