jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: JDBCDiskCache as Remote Cache
Date Fri, 03 Nov 2006 17:11:47 GMT
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


Mime
View raw message