Rickard,
Can you add some more information about how one might
approach implementing a synched cache with minimum overhead?
Peter Booth
----- Original Message -----
From: "Rickard �berg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 29, 2000 2:51 AM
Subject: Re: optimistic locking and deadlock (was EBs are slow)
> > > There would be two ways I think:
> > > * dedicate each node to a particular entity -> no need
> > > to update
> > > * Use a CMP implementation that does synched cluster
> > > caching. Use, for example, timestamps for optimistic
> > > concurrency control, or global locks for pessimistic CC
> >
> > > The latter /w OCC would be the more likely case I guess.
> >
> > The former precludes object failover, which is the primary reason for
> > clustering in the first place.
>
> No, it would not. If the node running the entity failed the cluster
> could fail over to use another cluster node.
>
> > The latter requires so much overhead (and serialization) that any
benefit
> > derived from Option A (entity caching in the container) is lost.
>
> It is very possible to implement a synched cache with minimal overhead
> and *no* serialization (you are making way too many assumptions about
> the implementation here), hence making Option A caches very nice for
> performance, especially in read-mostly scenarios (no db access at all
> for extended periods of time).
> I will demonstrate this in source in jBoss later on.
>
> /Rickard
>
>
===========================================================================
> 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".
