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:18:30 GMT
Aaron,

Thank you very much for responding.

I am certainly not avoiding the remote server implementation, but I am
concerned about how it will scale in our case. We have a very large
working set and the individual lateral cache clients hold data unique to
them. For example, say I have 5 cache clients that share only 30% of
their cached working set. I believe then that if X is the given cache
size, the remote server would have to be sized 30% + 5 * 60%, or 330% of
X. Given this, I would rather just have the 5 cache clients w/o a remote
cache. Let me know if this logic is flawed.

I was thinking along the same lines as you with a "shared" type. Clearly
the original disk cache is not sharable, but the JDBC disk cache should
be.... and that is what I am trying to do :-).

Randy

On Fri, 2006-11-03 at 08:57 -0800, Aaron Smuts 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