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 <[EMAIL PROTECTED]> 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]
