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 <[EMAIL PROTECTED]> 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: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
