> The benefit is that keeping the remote caches in synch lowers the potential
> for dirty check failures. Presumably it is better to have an updated cache
> if possible. And yes this is offset by the cost of keeping the caches in
> synch in the first case. Depends on update frequency...
I can't see how you can do that. If you synchronize multiple VMs, you
get both to be as accurate and timely as a single VM. GemStone appears
to be one of the better companies in multi-VM support, so I trust that
you can do it.
But you still need dirty checking if updates can occur from the outside,
as in direct JDBC access. I don't see how you can let go of dirty
checking at all. If you can then a distributed cache would make a lot of
sense.
> As a side note we don't broadcast changes at the object level, but rather
> synch at the page level. Makes for fewer network round trips which is where
> you usually get burned.
Beautiful.
arkin
>
> -Chris.
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
