Thanks for your quick reply.
Just to recap (and excuse me for being lazy - I'm sure all this is in a spec
somewhere!):
If I don't use commit option C, then the ejb server cluster will
*automatically* ensure that synchronization between object states is performed
such that if I update object a in server a and commit, then the update is
immediately applied in object a in server b.
Is there a way I can also check that object a has changed in another server b
before I commit - (Ie perform optimistic locking) without having to go to the
database?
Rickard �berg wrote:
> On Wed, 23 Aug 2000 11:23:01 +0100, Tim Fox <[EMAIL PROTECTED]> wrote:
>
> >I have a question on the maintaining of state consistency and
> >scalability on ejb servers.
> >
> >If I have, say, two ejb servers working in a load-balanced arrangements.
> >
> >Both servers are serving the same ejb classes.
> >
> >Client A is editing the Customer entity bean relating to "John Smith" on
> >server A.
> >The Customer entity bean relating to "John Smith" is also cached in
> >memory on server B after a previous update. (I am assuming ejb servers
> >cache objects in memory)
> >
> >Client A commits his changes to the underlying database.
> >How does ejb ensure that the in memory cached instance of "John Smith"
> >on server B is updated to reflect the changes made by Client A?
> >Does it fire off an "update" event to all the servers?
>
> There are many possible ways to do this, but yes, sending "update"
> events would be one way to do it.
>
> >If so, and we have n servers then I image we have a scalability problem
> >of order n-1. (Ie the server has to notify every other server that the
> >update has happened)/
>
> If a real messaging system is used the effects wouldn't be that bad
> (i.e. message batching and routing, etc.).
>
> >If it doesn't then how can I possibly use entity beans in a load
> >balanced environment?
>
> Many take the "easy" way out and use commit option C (i.e. passivate on
> tx commit). That way you never cache more than you have to and rely on
> the database for caching and locking and sychronization. How the DB
> performs this, well that's another story altogether..
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.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".
--
Tim Fox (��o)
Hyperlink interactive
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
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".
