jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: JDBCDiskCache as Remote Cache
Date Fri, 03 Nov 2006 18:20:40 GMT
Aaron,

Cool. I was going to try this out today after reviewing the
ramifications in the code of claiming the JDBCDiskCache was remote. It
is encouraging to hear that you think this might work as well!

Thanks for the continued feedback.

Randy

On Fri, 2006-11-03 at 09:11 -0800, Aaron Smuts wrote:
> You could of course, create a wrapper for the jdbc
> disk cache that returned the remote type.  Just extend
> it and override that method.  That would be a hack,
> but it's easy since JCS is pluggable.
> 
> --- Aaron Smuts <asmuts@yahoo.com> wrote:
> 
> > The remote cache doesn't work the way you described
> > exactly.  If a remove request goes to the remote
> > server, it sends it to all listeners and to all
> > auxiliaries.  There is no command to remove from
> > memory only.  
> > 
> > Just like the lateral cache, it can be configured to
> > send remove requests.  If you have the lateral
> > client
> > configured to get from the other laterals, then the
> > laterals start to look like a bunch of remote
> > caches. 
> > However, this is not advisable when  you have a buch
> > of machines.  You don't want to have to search 50
> > boxes for every cache miss. . . . .  
> > 
> > If you are using a shared jdbc disk cache, then
> > there
> > is no reason not to use the remote server.  I push
> > over 500 puts a second through a remote cluster and
> > do
> > the same number of gets . . .  If you are worried
> > about memory, then configure the remote server to
> > not
> > store very much or anything in memory.  That's how I
> > use it for most regions.  Use the remote cache as a
> > way to access the JDBC disk cache.  Also, the remote
> > will take care of the invalidation messages for you.
> > 
> > It is the most scallable way to go.  Also, you can
> > partition the data into multiple rmeote clusters in
> > the future if you needed to scale.   . . .
> > 
> > Hmmn.  I see what you are trying to do.  If the disk
> > cache was configured as a non-local auxiliary (i.e.
> > remote or lateral) then yes, the remove would not
> > remove the item from disk.  What we need is a new
> > type
> > called shared or remote disk.  This would do the
> > trick.        The assumption that all disk caches
> > are
> > local is false in this case.  Perhaps we could use
> > the
> > disk mode setting.   . . . Let me think about it a
> > bit
> > more.  For now, I suggest that you use the remote
> > cache.
> > 
> > Cheers,
> > 
> > Aaron
> >  
> > 
> > --- Randy Watler <watler@wispertel.net> wrote:
> > 
> > > We are attempting to use a JDBCDiskCache in a
> > shared
> > > mode with multiple
> > > cache clients using it as their backing store. We
> > > are also interested in
> > > using the TCPLateralCache in "remove on put" mode
> > to
> > > help keep the
> > > clients roughly in sync where their extents
> > overlap,
> > > (albeit not at a
> > > transactional level). We are not using a remote
> > > cache because each cache
> > > client will have a largely orthogonal working set
> > in
> > > relation to the
> > > other clients and that would force the single
> > remote
> > > cache to hold a
> > > very large working set for no advantage.
> > > Conceptually speaking, we are
> > > attempting to use the JDBCDiskCache as a remote
> > > cache instead.
> > > 
> > > Therein lies a problem though. Because the
> > > JDBCDiskCache is in fact a
> > > disk cache, JCS propagates lateral updates as
> > > removes to this auxiliary
> > > cache. This ends up actually removing the elements
> > > from the
> > > JDBCDiskCache instead of simply removing the items
> > > from the memory cache
> > > as would happen if it were a remote cache.
> > > 
> > > I am wondering if it would be reasonable to allow
> > a
> > > JDBCDiskCache to
> > > masquerade as a remote cache by indicating that
> > its
> > > cache type is
> > > remote? This would seemingly allow the cache to
> > > operate as a "remote"
> > > disk cache. True?
> > > 
> > > Any comments/tips would be appreciated. Thanks,
> > > 
> > > Randy
> > > 
> > > 
> > > 
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jcs-users-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jcs-users-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > jcs-users-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > jcs-users-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message