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]
